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SECTION  1 
INTRODUCTION 


1.1  TASK  OVERVIEW 

The/oi stributed  Data  Process Topology  Evaluation  Project  is  being  conductid 
in  support  of  the  Rpjne  Air  Development  Center's  (RADC)  mission  to  proviie 
standards  and  technical  guidance  in  the  effort  to  develop  and  implemen 
distributed  data  processing  networks. 

1.2  TASK  OBJECTIVES 

The  purpose  of  this  project  is  to  develop  and  install  on  the  RADC  HIS  6130 
computer  facility  a  user-oriented  modeling  capability  for  computer  networks. 
This  capability  should  be  easy  to  learn  and  use,  provide  an  easily  readable 
language  for  model  description,  minimize  the  time  and  effort  required  for 
model  development,  produce  easily  modifieo  models,  produce  models  that  are 
economical  to  run  and  produce  clear  and  concise  tabular  output  statistics. 

This  project  had  two  major  phases.  In  the  first  phase  a  simulator  development 
tool  called  the  Distributed  System  Simulator  (DSS)  has  been  developed  along 
with  three  high  level  models  of  computer  networks.  These  models  have  the 
ability  to  yield  performance  measures  to  evaluate  DDP  configurations  for  given 
workloads.  These  models  include,  as  a  minimum,  nodes  for  various  computers, 
varying  processing  loads  and  rates  for  each  node,  ana  different  band  widths  of 
communication  lines  between  nodes. 

During  the  second  phase,  DSS  has  been  used  to  develop  three  detailed  models  of 
computer  networks  using  the  ISO  Reference  Model  as  a  framework.  These 
detailed  models  include  a  communication  protocol  (CP)  model,  a 
reliability/availability  (R/A)  model  and  a  distributed  data  base  (DB)  model. 
These  models  follow  the  ISO  architecture  framework  in  that  each  succeeding 
model  uses  the  services  of  the  preceeding  model  in  a  hierarchical  fashiori. 
The  communication  protocol  model  simulates  the  X.25  interface  for  packet 
switched  networks  (levels  one  through  three  of  the  ISO  Reference  Model). 
Adaptive  routing  procedures  necessitated  by  nodal  failures  are  simulated  in 
the  reliability/availability  model. 
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Finally  OSS  was  used  to  build  a  distributed  data  base  model  (the  application 
le/el,  layer  7,  of  the  ISO  reference  model)  using  the  facilities  provided  by 
the  CP  and  R/A  models. 

1.3  THE  DISTRIBUTED  SYSTEM  SIMULATOR  (OSS) 

The  Distributed  System  Simulator  (OSS)  has  been  developed  as  a  modeling  tool 
to  facilitate  the  performance  analysis  of  computer  networks  through  discrete 
event  simulations.  There  are  two  broad  categories  of  problems  that  had  to  be 
addressed  in  designing  DSS.  The  first  is  the  large  set  of  problems  which 
naturally  arise  in  providing  a  simulation  tool  that  would  be  applicable  to 
many  types  of  computer  networks.  Even  a  brief  survey  of  the  literature 
describing  computer  networks  and  the  likely  developments  in  the  future 
strongly  suggest  that  there  are  no  typical  networks.  The  design  of  computer 
networks  is  in  its  infancy  and  therefore  constantly  evolving  on  both  the 
software  anc  hardware  levels. 

The  second  broad  problem  that  the  design  of  DSS  has  addressed  is  the  fact  that 
simulation,  expecially  of  diverse  and  complex  systems  such  as  computer 
networks,  can  be  a  time  consuming  and  costly  exercise.  DSS  has  been  designed 
to  minimize  the  development  time  of  simulators  and  to  aid  in  their  debugging 
ana  verification  phases.  DSS  is  a  precompiler  which  has  as  a  subset  a 
language  specifically  designed  for  simulating  single  and  multiple  processing 
systems  called  ECSS  (Extendable  Computer  System  Simulator)  [DOSY  75].  The 

output  of  DSS  is  an  ECSS  program  which  is  translated  into  Simscript  II. 5, 

compiled  and  run.  OSS  has  been  designed  as  a  modelling  tool  which  has  special 
facilities  for  simulating  a  broad  range  of  computer  networks. 

1.4  BACKGROUND 

A  survey  of  research  efforts  on  the  simulation  of  computer  networks  reveals 
two  major  parellel  trends.  The  first  is  the  development  of  special-purpose 
high-level  languages  to  simulate  computer  systems.  These  include,  among 

others  ASPOL  [MACD  13],  CSS  (an  IBM  product)  [SEAM  69],  and  ECSS  II 
(Extendable  Computer  System  Simulator)  [KOSY  75,  UNGE  78].  Generally  these 
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languages  have  evolved  from  high-level  languages  such  as  FORTRAN  and  ALGOL  68 
or  general-purpose  simulation  language'^  such  as  Simscript  II. 5  [KIVI  72]. 

Simulation  can  be  a  time  consuming  and  costly  exercise.  Special-purpose 

simulation  languages  help  to  alleviate  this  problem.  They  make  tne 

specification  of  computer  systems  easier.  Trade  facilities  and  detailed 
output  reports  reduce  the  time  needed  to  verify  and  validate  a  simulator.  A 
typical  problem  with  such  languages  is  that  increased  specialization  implies 
decreased  flexibility.  ECSS  II,  along  with  some  other  languages,  has  solved 
this  problem  by  allowing  all  valid  Simscript  II. 5  statements  in  an  ECSS 
simulator.  This  is  an  important  factor  in  the  usefulness  of  these  languages 
since  high-level  constructs,  which  reduce  the  time  needed  to  build  most 
simulators,  cannot  be  expected  to  meet  all  model's  needs.  The  next  lower 
le/ei,  Simscript  II. 5  in  the  case  of  OSS,  provides  complete  flexibility 
(Figure  1.4-1). 

The  second  major  trend  is  that  some  of  these  simulators  have  increasea 

applicability  with  respect  to  the  range  of  the  systems  they  can  model.  At  one 
end  of  the  spectrum  are  (see  Figure  1.4-2)  case  studies,  specially  designed 
simulators  to  study  particular  problems  of  computer  systems  [MACD  67,  HUH 
73].  Usually  these  simulators  are  not  used  once  the  modeling  project  for 
which  they  were  designed  has  ended.  Simulators  with  a  wider  scope  of 
applicability  are  parametric  models  [PRIC  77,  SHOE  73].  With  these  simulators 
it  is  possible  to  vary  certain  well-defined  parameters  such  as  the  input  rate 
of  application  jobs  and  average  message  lengths.  By  varying  the  input 
parameters,  it  is  possible  to  perform  a  range  of  experiments.  However,  these 
simulators  are  restricted  to  very  specific  assumptions  about  the  system 
architecture  being  modeled.  Further,  the  user  cannot  change  the  network 
protocols,  such  as  routing  algorithms  and  flow  control  procedures.  A 
simulator  that  goes  beyond  the  limitation  of  parametric  models,  called  a 
structural  simulation  model,  has  been  developed  [SCHN  78].  This  system,  named 
VANS  (Value  Added  Network  Simulator),  assumes  that  the  communications  network 
is  a  store-and-forward  packet-switched  network  like  the  ARPANET.  Instead  of 
having  fixed  protocols,  the  user  may  replace  a  subprogram  that  is  currently 
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■J60MPUTER  SYSTEM  SIMULATOR  (CSS) 


•  TOPOLOGY  FILE 

•  MODEL  LIBRARY 

•  SYSTEM  DESCRIPTIONS 

•  MORKLOAO  DESCRIPTIONS 

•  RESOURCE  MANAGERS 

■ 

•  INTERACTIVE  USER  INTERFACE 

•  ECSS  HIGH  LEVEL  CONSTRUCTS 

1 

•  SIMSCRIPT  II. S 

•  PROCESSES 

•  ROUTINES 

•  INTERACTIVE  USER  INTERFACE 

■ 

■ 

LEVEL  I 

LEVEL  II 

level  III 

Figure  1.4-1  OSS  Model  Description  Levels 


SPECIFIC  GENERAL  MODEL  LIBRARY 


CASE  PARAMETERIZED  STRUCTURAL 

STUDIES  MODELS  MODELS 


Figure  1.4-2  Range  of  Model  Generality  -  Case  Studies 
to  Model  Libraries 
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SECTION  2 
OVERVIEW  OF  DSS 


OSS  has  been  designed  as  a  modeling  tool  to  facilitate  the  performance 
analysis  of  computer  systems  and  networks  through  simulation.  It  is 
implemented  in  Simscript  II. 5  (an  event  oriented  simulation  language)  and  ECSS 
II  (a  special-purpose  simulation  language  designed  to  simulate  computer 
systems).  The  OSS  models  may  use  any  of  the  statements  from  these  two 
languages;  its  major  function  is  to  extend  the  capability  of  these  languages 
to  model  computer  networks. 

A  separate  DSS  model  can  simulate  a  single  node  in  a  computer  network.  (A 
node  is  simply  a  collection  of  system  components  that  communicate  with  other 
components  of  the  network  over  some  transmission  medium.  See  Section  2.1  for 
a  fuller  description.)  If  two  or  more  nodes  have  similar  characteristics,  OSS 
can  duplicate  the  model  as  many  times  as  there  are  similar  nodes.  This 
capability  greatly  reduces  the  amount  of  code  to  be  generated  by  the  user. 
These  OSS  models  are  then  combined  to  form  a  simulator  of  the  entire  network. 
OSS  models  are  not  limited  to  simulating  a  specific  architecture  or  set  of 
protocols  since  they  have  access  to  all  of  the  high-level  constructs  of  ECSS 
II  and  Simscript  II. 5.  There  are  several  advantages  to  having  a  separate 
model  for  each  node.  First,  DSS  provides  the  capability  of  debugging  and 
verifying  OSS  models  separately.  In  a  network  with  fifty  nodes,  there  may  be 
only  two  distinct  DSS  models:  one  for  the  switching  computers  and  one  for  the 
host  sites.  Instead  of  trying  to  verify  a  fifty-node  network  simulator,  the 
problem  is  reduced  to  verifying  two  OSS  models  separately.  The  second 
advantage  is  that  a  library  of  DSS  models  may  be  created  that  can  focus  on 
particular  network  problems,  such  as  flow  control  or  routing  algorithms. 
These  DSS  models  nay  be  used  again  in  other  simulators  so  that,  as  the  library 
grows,  the  time  to  build  a  simulator  can  be  reduced  in  some  cases.  In  this 
sense  DSS  is  an  extendable  system. 

DSS  has  an  internodal  communication  facility  that  is  the  mechanism  by  which 
one  DSS  model  communicates  with  another.  This  facility  allows  messages  cf 
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arbitrary  size  and  content  to  be  passed  between  models  without  presuppositions 
concerning  the  communication  protocols  that  are  simulated.  In  other  words, 
the  DSS  communication  facility  is  the  means  by  which  separate  OSS  models  are 
connected  to  form  a  simulator  of  an  entire  network  without  biasing  the  user  to 
favo''  one  communication  protocol  over  another. 

There  are  three  main  input  files  to  DSS  that  a  user  must  supply.  The  first  is 
the  file  consisting  of  the  DSS  models.  These  models,  described  in  Section  2.3 
may  na/e  been  previously  defined  or  created  by  the  user.  The  second  input 
*':e  i:  ‘.re  topology  file  (TP.FIlEi.  This  file  describes  the  internodal  paths 
conneccing  tne  nodes  in  the  network.  The  third  file  (M.FILE)  specifies  for 
eacn  node  or  subsystem  in  tne  network  the  particular  OSS  model  that  will 
simu  ate  it.  The  user  creates  these  files  at  a  terminal.  The  DSS  is  a 
precompiler  that  has,  as  a  subset,  a  language  (ECSS)  specially  designed  for 
simulating  single  and  multiple  processing  systems.  The  output  of  DSS  is  an 
ECSS  program  that  is  translated  into  Simscript  II. 5,  compiled  and  run  (Figure 
2-1). 


2.1  NODAL  MODELS 

OSS  views  a  computer  network  as  a  set  of  interconnected  nodes  that  communicate 
with  each  other  over  some  transmission  medium.  At  each  of  these  nodes  reside 
computer  resources,  such  as  hardware  devices,  protocol  handlers  and  data 
bases.  This  view  of  computer  networks  is  very  general,  so  that  a  broad  range 
of  networks  from  local  area  networks  to  geographically  dispersed  packet 
switched  networks  may  be  modeled. 

The  user  describes  eacn  node  separately.  Models  for  nodes  with  similar 
characteristics  may  be  duplicated  automatically.  The  total  network  model  is  a 
collection  of  these  separate  nodal  models.  The  degree  of  detail  in  each  of 
these  nodal  models  determines  the  level  of  detail  ot  the  entire  network 
model.  For  example,  a  work  station  in  a  local  area  network  that  communicates 
with  other  stations  over  a  shared  bus  may  be  viewed  as  a  separate  node.  In  a 
satellite/terrestrial  system,  the  satellite  and  earth  stations  may  be  modeled 
as  individual  nodes.  On  a  more  global  level,  an  entire  local  area  network  may 
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Figure  2-1  Overview  of  DSS 


be  modeled  as  a  separate  node  that  communicates  with  other  networks  through 
gateways.  The  nodal  models  are  stored  in  a  model  library  to  be  used  as 
needed.  There  may  be  both  separate  user  libraries  and  a  system  wide  library 
that  all  users  may  access. 

Each  nodal  model  is  an  ECSS  program. 

DSS  extends  the  capabilities  of  ECSS  in  two  important  ways: 

•  A  library  of  models  may  be  developed  that  can  be  used  in  more  than  one 
simulator. 

•  Nodal  models  can  be  duplicated  any  number  of  times  for  similar 

subsystems  in  the  overall  network. 

This  allows  DSS  to  be  an  extendable  system  and  minimizes  the  time  needed  to 
build  simulators.  To  provide  these  capabilities,  DSS  is  a  preprocessor  of 
ECSS  programs.  ECSS  output  is  translated  into  Simscript,  compiled,  and  run. 
Models  may  reside  in  the  model  library  as  compiled  programs,  reducing  initial 
configuration  time. 

Rega'-dless  of  the  detail  level  of  a  node,  each  node  may  be  modeled  as  the 
inte^'action  of  three  main  components:  a  set  of  resources  with  finite 

capacity,  (System  Description);  the  tasks  or  demands  the  system  is  designed  to 
service  (Workload  Description);  and  the  allocation  policies  that  determine  how 
these  resources  are  to  be  apportioned  among  the  jobs  (Resource  Manager 

Description).  The  next  three  subsections  describe  each  of  these  components. 
Section  2.2.5  gives  an  example  of  a  complete  nodal  model  using  the  System 
Description,  Workload  Description,  and  Resource  Manager  sections. 

2.2  EXTENDABLE  COMPUTER  SYSTEM  SIMULATOR  (ECSS) 

ECSS  is  a  high  level  simulation  language  especially  designed  to  simulate 
single  or  multiple  processing  systems.  ECSS  contains  as  a  subset  Simscript 
II. 5  which  is  a  general  purpose  simulation  language  [KIVI  73].  The  main 
purpose  of  this  section  is  to  highlight  major  parts  of  ECSS  so  that  the 

following  sections  of  this  report  may  be  more  easily  understood.  A  more 
comprehensive  view  of  ECSS  is  contained  in  [KOSY  75]. 
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2.2.1  SYSTEM  DESCRIPTION 

The  System  Description  section  defines  the  system  resources  in  terms  of 
hardware  devices,  their  characteristics  and  interconnections.  There  are  five 
basic  types  of  devices,  each  with  its  own  set  of  properties. 

•  Private  devices 

•  Storage  devices 

•  Processor  devices 
e  I/O  devices 

•  Job  store  devices 

The  name,  number  of  members,  and  characteristics  of  a  class  of  devices  are 
declared  by  a  SPECIFY  statement: 

SPECIFY  I  Device  Class  Name  EACH 

Characteristic  Clauses 

An  example  of  a  SPECIFY  statement: 

SPECIFY  2  PROCESSORS  EACH 

EXECUTES  500000  INSTRUCTIONS/SEC, 

STORES  JOBS  FOR  EXECUTION, 

TRANSMITS  50000  BYTES/SEC 

In  this  statement  two  processors  are  defined.  Each  one  has  three  specific 
properties  defined  by  the  characteristic  clauses.  As  this  example 
illustrates,  a  device  may  have  properties  from  more  than  one  of  the  five  basic 
types  of  devices.  'I'  is  the  number  of  devices  being  defined  in  the  SPECIFY 
statement.  'Device  Class  Name'  is  an  arbitrary  variable  name,  and  a 
'Characteristic  Clause'  defines  a  property  from  one  of  the  five  basic  types  of 
devices.  There  is  a  total  of  10  possible  characteristic  clauses  that  describe 
the  properties  of  the  basic  device  types. 
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The  interconnections  between  devices  are  defined  in  the  System  Description 
Section  by  means  of  PATH  statements  with  the  general  form: 


PATH  name  CONNECTS 
Device  Name  1  TO 
Device  Name  2  TO 

Device  Name  N 

'or  example,  assuming  that  devices  DISK  and  CHANNEL  were  defined  by  SPECIFY 
statements,  they  may  be  interconnected  by  the  PATH  statement: 

PATH  10  CONNECTS 
DISK  TO 
CHANNEL 

The  System  Description  section,  as  can  be  seen  from  these  examples,  is  a  high 
level,  self  documenting  language. 

2.2.2  WORKLOAD  DESCRIPTION 

The  second  major  part  of  a  nodal  model  is  the  Workload  Description  section. 
This  is  where  the  load  on  the  resources  of  a  computer  system  is  described. 
The  basic  component  of  this  section  is  a  simulation  process  that  may  be 

described  as  a  sequence  of  related  events.  For  example,  the  pattern  of 

resource  requests  that  comprise  a  computer  job  may  be  defined  as  one  process. 

A  job  is  initiated  on  a  particular  processor  by  the  statement: 

START  A  Job  Name  ON  Device  Name  WITH  PRIORITY  E 

'Job  Name'  is  the  unique  identifying  name  for  the  job;  'Device  Name'  is  the 

predefined  processor  device  on  which  the  job  is  to  run;  'E'  is  the  priority  of 
the  job,  i.e.,  higher  priority  jobs  interrupt  lower  priority  jobs  on  the 

processor  (this  may  be  varied  as  described  in  the  Resource  Manager  Section). 
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Two  examples  of  the  basic  statements  that  simulate  resource  requests  of 
computer  jobs  are  as  follows. 


Example: 

EXECUTE  N  INSTRUCTIONS 

The  'EXECUTE'  statemeht  holds  a  processing  device  for  a  time  that  depends  on 
the  instruction  rate  of  the  processor  and  the  number  of  instructions  in  the 
statement.  The  processor  is  the  device  upon  which  runs  the  job  that  was 
declared  in  the  START  statement  at  activation  time. 

Example: 

SEND  N  DATA. UNITS  VIA  PATH  NAME 

The  SEND  statement  causes  a  set  of  I/O  devices  to  be  held  for  a  simulated 
time.  This  set  is  specified  Implicitly  by  the  'PATH  NAME'  that  had  previously 
been  defined  in  the  System  Description  section  and  that  logically  connects  a 
string  of  devices  such  as  channels  and  disks.  The  length  of  the  simulated 
time  depends  on  the  transmission  speed  of  the  slowest  device  at  either  end  of 
the  path  and  the  number  of  DATA. UNITS  in  the  SEND  statement. 

2.2.3  RESOURCE  MANAGER  DESCRIPTIONS 

The  allocation  policies  for  the  resources  of  a  node  depend  on  the  operating 
system.  This  component  of  real  systems  is  simulated  by  resource  managers. 
There  is  a  resource  manager  for  each  of  the  five  basic  types  of  devices.  For 
example,  when  a  job  runs  on  a  particular  processor,  the  order  in  which  it  will 
be  served  (e.g.,  round  robin  or  pre-emptive  priority)  is  determined  by  the 
Execution  Manager.  EXECUTE  statements  in  jobs  invoke  the  Execution  Manager. 
Resource  managers  are  ECSS/Simscript  routines  to  which  the  user  has  access  and 
which  he  may  alter.  This  factor  gives  DSS  great  flexibility  in  the  types  of 
operating  systems  that  may  be  simulated. 
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By  dividing  a  nodal  model  into  the  three  categories  of  System  Description, 
Workload  Description  and  Resource  Managers,  it  is  possible  to  run  one  Workload 
Description  section  using  the  System  Description  section  of  another  simulator 
(providing  the  names  of  the  devices  are  compatible).  This  feature  is  quite 
valuable  when  performing  simulation  experiments  for  different  computer  design 
alternatives.  The  amount  of  simulator  effort  is  greatly  reduced. 

2.2.4  SIMSCRIPT  II. 5 

As  stated  above  ECSS  is  a  superset  of  Simscript  II. 5.  Any  Simscript  statement 
is  allowed  in  an  ECSS  program.  Simscript  II. 5  is  a  full  programming  language 
designed  specifically  for  simulation.  Simscript  II. 5  provides  a  general 
purpose  high-level  base  language,  comparable  in  power  with  PL/1  and  ALGOL. 
The  base  language  is  augmented  with  the  facilities  necessary  for  simulation: 


•  The  entity-attribute-set  “world  view"  of  Simscript 

•  Both  internal  and  external  events 
«  Process  and  resource  orientation 

•  A  large  collection  of  random  number  distribution  generation  procedures 

-  Beta  -  Log  Normal 

-  Binomial  -  Normal 

-  Erlang  -  Poisson 

-  Exponential  -  Uniform  (Discrete) 

-  Gamma  -  Uniform  (Continuous) 

-  Hyperexponential  (DSS)  -  Weibull 

-  Hypoexponential  (DSS) 

•  Automatic  statistics  collection,  triggered  by  the  nonprocedural 
ACCUMULATE  and  TALLY  operations 

•  The  report  generator  of  Simscript 


Simscript  II. 5  is  implemented  to  handle  large 
storage  is  provided  for  all  data  structures. 


simulation  models. 


Virtual 
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2.2.5  AN  EXAMPLE  OF  A  COMPLETE  NODAL  MODEL 

In  this  section  we  briefly  describe  how  the  various  statements  from  the  System 
Description,  Workload  Description  and  Resource  Manager  Sections  can  be 
combined  to  form  a  complete  nodal  model.  The  model  will  represent  an  on-line 
text-editor  system.  This  model  may  be  saved  in  the  model  library  and  used  as 
a  stand-alone  model  or  combined  with  other  models  from  the  library  to  form  a 
larger  network-wide  model.  (This  example  is  taken  from  the  ECSS  User's  Manual 
[KOSY  75]). 

The  configuration  for  this  hypothetical  system  being  modeled  is  depicted  in 
Figure  2. 2. 5-1.  It  consists  of  a  central  computer,  two  channels,  three 
random-access  disks,  20  terminals,  and  a  printer.  Although  one  of  these 
elements  does  contain  a  processor,  there  are  also  I/O  devices,  data  paths, 
storage  and  other  types  of  resources.  This  hardware  is  to  be  used  for  on-line 
text  editing  by  up  to  20  users  simultaneously.  The  System  Description  section 
and  the  Workload  Description  section  which  model  this  configuration  are  shown 
in  Figure  2.2. 5-2.  Lines  1  through  30  of  this  figure  constitute  the  System 
Description  section.  At  the  top  of  this  Section,  a  device  called  CPU  is 
specified  to  have  three  components:  a  job  store,  a  processor,  and  a  storage 
component.  Since  all  users  employ  the  same  text-editor  program,  the  system 
has  been  designed  such  that  enough  main  memory  has  been  set  aside  to  contain 
it,  including  a  block  of  working  storage  for  each  user.  We  are  not  interested 
in  this  portion  of  memory  in  this  model,  thus  it  is  not  represented.  We  are 
interested  in  the  remaining  memory  which  is  divided  into  ten  message  buffers 
that  can  be  allocated  dynamically  to  users  as  necessary,  and  four  batch 
partitions.  We  assume  that  each  buffer  and  partition  is  identical  to  the 
others,  so  its  actual  size  does  not  matter  in  the  model.  The  time-unit  for 
this  model  is  a  second;  and  so  the  CPU's  average  execution  rate  is  100,000 
instructions/  second. 

The  twenty  TERMINALS  are  private  I/O  devices  having  a  150  character/second 
transmission  rate.  They  are  private  because  we  will  want  to  allocate  one  to 
each  user  exclusively. 


t  ion 


Figure  2. 2. 5-1  System  Configure 


CHI  represents  a  3-port  multiplexor  channel  and  CH2  represents  a  selector 
channel.  Since  no  transmission  rates  have  been  specified,  messages  between 
them  will  proceed  at  the  speed  of  the  devices  to  which  they  connect. 

The  three  DISKS  are  I/O  devices  which  can  transfer  data  at  32,000 
bytes/second.  They  are  fixed  head  disks  with  a  rotational  period  of  40 
milliseconds  and  contain  2  records  per  track.  The  average  latency  is  2') 
milliseconds.  Text  files  for  the  various  users  are  stored  on  each  disk. 

One  disk,  designated  as  the  MASTER-DISK,  also  stores  a  file  used  to  check  tne 
validity  of  a  user's  account  number  at  log  on,  ana  to  record  systen 
utilization  data  for  billing  purposes.  When  this  file  is  in  use,  it  is 
protected  from  tampering  by  using  the  ACCT.FILE  private  device  as  a  software 
lock . 

The  PRINTER  is  a  simple  I/O  device  representing  a  600  line  per  minute 
printer.  The  last  lines  in  the  system  description  indicate  the  data  paths 
connecting  the  channels  to  each  of  the  other  I/O  devices.  Although  the  CPU 
will  not  participate  in  simulated  I/O  operations,  its  logical  connection  to 
the  channels  is  indicated  in  the  CONNECTS  clause. 

As  in  any  model,  this  is  a  simplification  of  a  real  system.  For  example,  no 
consideration  has  been  given  to  disk  or  terminal  control  units,  though  these 
could  be  easily  added  if  considered  important  to  system  performance.  Using  an 
average  latency  is  another  simplification  which  could  be  modified  by  supplying 
a  latency  function.  In  general.  System  Descriptions  are  written  to  include 
only  the  most  important  resources,  described  at  ^  level  of  detail  consistent 
with  the  rest  of  the  model.  This  example  is  not  meant  to  be  a  complete 
presentation  of  the  model  description  language,  but  serves  only  to  give  an 
indication  of  its  self -documenting  nature  and  the  wide  range  of  resources  that 
may  be  defined.  Overhead  clauses  are  not  necessary  and  may  be  left  out  of  a 
System  Description  section  when  the  level  of  detail  permits  it. 
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Line  29  declares  that  the  CPU  is  allocated  to  jobs  on  a  round  robin  basis. 
Tne  default  manager  for  processor  devices  is  first-come-first-served. 
Changing  this  one  line  in  effect  changes  the  operating  system  model  (that  is, 
the  resource  manager  for  the  CPU)  without  having  to  change  any  other  lines  in 
tne  model.  There  is  a  library  of  resource  managers  available  to  the  user. 
Alternatively,  the  user  may  choose  to  write  his  cwn  resource  manager  for  3 
particular  device  or  class  of  devices.  This  new  manager  would  be  given  i 
unique  name  and  stored  in  a  system  wide  or  user-defined  library  for  resource 
managers.  We  now  turn  to  the  WorKload  Description  section. 

For  this  example,  each  user  at  his  terminal  makes  a  related  series  of  demanos 
on  the  system,  which  cause  different  kinds  of  internal  operations  and  requires 
rapid,  interactive  responses.  The  applications  programs  driving  the  system 
must  produce  these  responses  and  perform  the  operations.  This  activity 
includes  logging  users  in  and  out,  transferring  text  data  from  disk  storage  to 
main  memory  and  back,  performing  the  editing  operations,  and  printing  the 
results,  thus  utilizing  proce-.sor,  storage,  I/O  and  other  resources  as 
necessary  for  each  function.  Using  a  model,  it  is  possible  to  determine  the 
average  time  it  takes  to  respond  to  a  user  request,  and  to  evaluate  the  effect 
of  different  numbers  of  users  on  response  time,  the  utilization  of  each 
device,  the  effect  of  queueing  delays,  to  determine  how  the  system  performs 
under  various  conditions,  and  to  indentify  the  important  factors  in 
determining  that  performance. 

The  WorKload  Description  section  for  tins  hypothetical  system  is  described  in 
lines  32  through  100  of  Figure  2.2.5-?.  It  contains  three  processes:  one 
external  process  ana  two  jobs. 

•  The  External  Process  UScR 

Lines  34  through  55  describe  the  behavior  of  each  user.  The 

statements  represent  tne  events  and  activities  charted  in  Figure 

2. 2. 5-3  which  is  a  scenario  of  text  editing  behavior. 
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•  Tne  TEXT. EDITOR  Job 

Tne  TEXT. EDITOR  job  defined  by  lines  57  through  94  is  more  complex 
than  tne  user  process.  It  contains  more  activities  and  uses  more 
resources.  All  jobs  in  tms  model  are  executed  by  the  CPU  processor 
concurrently,  i.e.,  the  processor  is  mul ti programmed. 

•  Tne  LISTQFF  Job 

Tne  LISTOFr  job  described  by  lines  95  through  99  represents  data 
transfer  from  a  text  file  to  main  memory  ana  then  to  the  printer. 
The  amount,  (LNS),  is  interpreted  as  the  number  of  lines  averaging  80 
bytes  per  I'ne.  The  text  file  is  specified  by  tne  number  of  the  disk 
on  rthich  it  is  stored.  A  single  message  represents  the  entire 
printing  activity;  consequently,  there  is  no  danger  that  segments  of 
different  listings  will  be  interspersed  by  LISTOFF  jobs  competing  for 
tne  printer. 

Jobs  may  be  parameter i zed  so  as  to  have  general  processing  characteristics. 
Each  job,  under  its  own  name,  may  be  saved  in  a  Workload  Description  library 
tnat  is  user  specific  or  available  on  a  system-wide  basis.  For  instance, 
tnere  may  be  a  graphics  output  job  called  JOB  GRAPHICS  that  requires  as 
parameters  (which  may  be  defined  as  a  menu  of  options)  the  format  and  data 
rate  of  the  graphical  output  to  be  modeled.  This  job  would  then  simulate  the 
CPU,  Channel,  and  disk  overhead  that  would  be  incurred  by  a  real  graphics 
display  terminal . 

It  Should  be  noted  tnat  each  major  component  of  a  nodal  model  (the  System 
Description,  Workload  Description,  and  Resource  Manager  sections)  allows  for 
tne  ;onstruction  of  models  in  a  modular  fashion.  Changes  in  one  component  do 
not  necessitate  changes  to  another  component.  In  this  brief  example,  the 
workload  could  be  redefined  and  scientific  application  jobs  run  against  the 
same  System  Description  and  Resource  Manager  sections.  This  modularity 
facilitates  the  running  of  model  experiments  as  system  components  are  varied. 
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2.3  DSS  MODELS 

As  sr.ated  above  a  DSS  model  is  essentially  an  ECSS  program  that  models  the 
activity  within  a  single  node  of  a  network.  The  user  may  design  different  DSS 
■'Models  independently  and  later  connect  the  models  to  form  a  simulator  for  a 
network.  This  capability  to  simulate  a  node  with  an  individual  DSS  model 
encourages  a  modular  approach  to  the  design  of  network  simulators.  Also, 
modifications  within  a  single  node  can  be  easily  made  without  changing  the 
rest  of  the  network  model.  Finally,  as  the  user  develops  new  DSS  'Models  they 
may  be  stored  in  a  DSS  Model  Library,  The  models  can  be  retrieved  and  used 
for  future  simulations. 

2.3.1  OSS  MODEL  DEFINITION 

Since  each  DSS  model  conforms  to  ECSS  syntax  it  may  contain  its  own  Preamble, 
System  and  Workload  Description  sections,  as  well  as  Simscript  routines.  Each 
DSS  model  must  be  bracketed  by  a  model  number  statement  (eg..  Model  #1)  and  an 
END  statement.  Table  2. 3. 1-1  is  a  schematic  representation  of  the  basic 
structure  of  a  DSS  model.  An  entire  program  file  consisting  of  several  DSS 
models  is  outlined  in  Table  2.3. 1-2.  Generally  a  OSS  simulation  consists  of 
more  than  one  model  from  the  DSS  model  library.  Figure  2. 3. 1-2  is  an  actual 
example  of  a  DSS  simulation  program. 
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Table  2. 3. 1-1  Standard  DSS  Model  Program  File 


MODEL  #1 

PREAMBLE  [optional] 


■  Preamole  (optional) 

END  "PREAMBLE 
SYSTEM  DESCRIPTION 

.  System  Description 

END  "SYSTEM  DESCRIPTION 
WORKLOAD  DESCRIPTION 


Workload  Description 


END  "WORKLOAD  DESCRIPTION 
SIMSCRIPT  II. 5  ROUTINES 

.  Routines  (optional ) 

END  "MODEL  #1 

Figure  2. 3. 1-1  DSS  Model  Structure 


preamble  "SYSTEM  WIDE  PREAMBLE 


NETWORK  WIDE 
PREAMBLE 

END  "PREAMBLE 
MODEL  fX 

SYSTEM  DESCRIPTION 


WORKLOAD  DESCRIPTION 


CODE  FOR  MODEL  X 


ROUTINES 
END  "MODE.  *X 


MODEL  «Y 

SYSTEM  DESCRIPTION 


WORKLOAD 


CODE  FOR  MODEL  Y 


ROUTINES 
END  "MODEL  fY 


(optional 
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INSTRUCTIONS 


BYTES/SEC 


Table  2.3. 1-2  OSS  Model  Program  File  Sample 

PREAMBLE 

EVENT  NOTICES 
EVERY  MESSAGE  HAS  AN  10 
DEFINE  CLASS  AS  AN  INTEGER  VARIABLE 
END  "NETWORK  PREAMBLE 

MODEL  #1 
PREAMBLE 

PERMANENT  ENTITLES 
EVERY  ..NODE  OWNS  AN  OVERFLOW 
TEMPORARY  ENTITLES 

EVERY  ..MSG  MAY  BELONG  TO  AN  OVERFLOW 
END 

SYSTEM  DESCRIPTION 

SPECIFY  1  CPU,  WHICH  STORES  JOBS  FOR  EXECUTION 

EXECUTES  AT 

/  SEC 

SPECIFY  2  CHANNEL,  WHICH  TRANSFERS  MESSAGES  AT  2000000 

BYTES/SEC 

SPECIFY  10  TERMINAL,  WHICH  TRANSFERS  MESSAGES  AT 


SPECIFY  1  BUF,  WHICH  HAS  CAPACITY  OF  10000  DATA. UNITS 
PATH  T.PATH  CONNECTS  CHANNEL  TO  TERMINAL 
external  PROCESSES  ARE  CP 
JOBS  ARE  J8R 
END  "SYSTEM  DESCRIPTION 
WORKLOAD  DESCRIPTION 

EXTERNAL  PROCESS  CP  GIVEN  N 
LET  CLASS  =  1 
HERE  START  JBR  GIVING  N 
WAIT  FOR  SIGNAL 
LET  CLASS  -  1 
JUMP  SACK 
END  "CP 

JOB  JBR  GIVEN  N 

SEND  400  BYTES  FROM  CHANNEL  <f]  TO  TERMINAL  #8 

GET  1000  BYTES  FROM  BUF 

EXECUTE  5000  INSTRUCTIONS 

FREE  1000  BYTES  FROM  BUF 

SIGNAL  ..CP  (N) 

END  "JBR 

END  "WORKLOAD  DESCRIPTION 
ROUTINE  GOPHER 

FOR  I  =  1  TO  1000 
LOOP 
RETURN 
END  "GOPHER 
END  "MODEL  fl 


500000 


9600 
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Table  2. 3. 1-2  OSS  Model  Program  File  Sample  (Con't 

MODEL  #2 
PREAMBLE 

TEMPORARY  ENTITIES 

EVERY  ROOM  HAS  A  DOOR 
END  “PREAMBLE 
SYSTEM  DESCRIPTION 

SPECIFY  1  CPU,  WHICH  STORES  JOBS  FOR  EXECUTION, 

EXECUTES  AT  500000  INSTRUCTIONS  /  SEC 
SPECIFY  1  SUF,  WHICH  HAS  CAPACITY  OF  10000  DATA. UNITS 
EXTERNAL  PROCESSES  ARE  CP,  XYZ 
job:-  ARE  AKNOL 
END  "SYSTEM  DESCRIPTION 
WORKLOAD  DESCRIPTION 

EXTERNAL  PROCESS  CP  GIVEN  K 
HERE  IF  CLASS  =  1 

START  AKNOL  ON  CPU 
ALWAYS 
START  XYZ 
WAIT  5  SEC 
JUMP  BACK 
END  "CP 

EXTERNAL  PROCESS  XYZ 
WAIT  2  SEC 
LET  CLASS  =  0 
END  "XYZ 
JOB  AKNOL 

GET  1000  BYTES  FROM  BUF 
EXECUTE  1000  INSTRUCTIONS 
FREE  1000  BYTES  FROM  BOF 
END 

END  "WORKLOAD  DESCRIPTION 

ROUTINE  HOG  LET  X  =  TIME.S  +  4.0 
RETURN 
END  "HOG 
END  "MODEL  *2 


2.3.2  INTERNODAL  COMMUNICATION 

Because  OSS  models  are  created  independently  of  eacn  other  there  is  a  need  for 
a  standard  mechanism  for  inter-nodal  communication.  The  communication 
facility  within  OSS  was  designed  with  this  purpose  in  mind. 

In  a  network  with  M  nodes  each  of  the  nodes  has  an  active  instance  of  an 
external  process  associated  with  it  (Figure  2, 3. 2-1).  For  example,  node  2  is 
associated  with  external  process  CP02.  The  CPXX  process  (where  'XX'  stands 
for  a  nodal  number  from  1  to  N)  is  responsible  for  all  inter-nodal 
communication.  Communication  between  nodes  is  simulated  by  four  basic  steps. 

In  describing  these  steps  we  shall  assume  that  the  communication  between  two 
arbitrary  nodes  in  a  network,  called  N1  ai.d  N2,  is  to  oe  simulated,  and  that 
there  is  a  direct  link,  an  ECSS  path  named  101A.N1.N2  connecting  these  two 
nodes. 

STEP  1  Simulate  the  transmission  times  between  nodes  N1  and  N2  with  a 
standard  ECSS  SEND  statement  using  path.  The  form  of  this 
statement  is: 

SEND  n  data  units  VIA  I01A.N1.N2 

where  n  data  units  is  the  length  of  the  message  expressed  in  bits, 
bytes  or  some  other  previously  chosen  unit  of  information. 

After  the  delay  is  simulated  actual  message  data  must  be  passed  between  nodes 
N1  and  N2.  We  assume  that  a  message  entity  (simply  an  area  of  memory)  has 
been  created  with  information  contained  in  it  such  as  a  source,  destination 
and  intermediate  nodes  traversed.  Steps  2  and  3  are  responsible  for  this  part 
O'  tre  transmission. 

STEP  2  Put  a  pointer  to  the  message  that  is  being  sent  from  N1  to  N2  in 
the  message  file  of  node  N2.  The  code  for  this  step  is: 
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FILE  MSG  IN  ..MGFILE  (N2) 

where  MSG  is  a  pointer  to  the  defined  temporary  entity  which  is 
the  internodal  message;  ..MGFILE  is  a  FIFO  set  owned  by  the 
receiving  node,  in  this  case  node  N2.  OSS  creates  a  message  file 
called  ..MGFILE  for  each  node  which  can  be  indexed  by  node 
number.  In  this  way  each  node  has  its  own  message  file  reserved 
for  internodal  communication. 


STEP  3  Notify  the  communication  process  for  node  N2  (CP.N2)  that  it  has  a 
message  waiting  for  it.  The  code  for  this  step  is  the  standard 
ECSS  SIGNAL  statement: 

SIGNAL  ..CP  (N2) 

The  variable  called  ..CP  is  a  one  dimensional  array,  created  by 
OSS,  which  can  be  indexed  by  nodal  number.  It  contains  the 
pointers  to  the  unique  communicating  processes  for  all  of  the 
nodes. 

STEP  4  The  receiving  process,  CP.N2,  will  wake  up,  look  in  its  message 
file,  find  the  pointer  to  the  message  and  take  appropriate  action 
depending  on  the  destination  of  the  message,  its  priority,  type 
etc.  The  communication  process  CP.N2  will  be  in  a  wait  state  when 
signaled  by  a  job  or  process  at  node  Nl.  It  CP.N2  then  removes 
the  message  pointer  from  its  own  message  file,  . .MGF ILE(N2) ,  and 
processes  the  messages  in  some  way.  Typical  code  for  this  step 
would  be: 

WAIT  FOR  SIGNAL 

REMOVE  THE  FIRST  MSG  Code  in  CP.N2  for  accepting 

FROM  ..MGFILE(N2)  incoming  message. 

IF  PRIORITY  (MSG)  IS  ... 
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These  four  basic  steps  form  the  framework  for  simulating  trahsmission 
betweeh  neighboriog  hodes  regardless  of  the  type  of  network  which  is 
simulated. 

The  commuhicatihg  processes  are  simply  logical  constructs  whose  primary 
function  is  to  pass  data  from  one  node  to  the  next.  No  simulation  time  is 
incremented  for  any  of  the  actions  taken  by  these  processes.  A  communicating 
process  may  start  jobs  on  the  processing  units  for  the  node  with  which  it  is 
associated  but  the  jobs  are  the  users  of  computer  resources,  not  the 
coTTiunicating  process.  The  communication  process  within  a  DSS  Model  is  always 
called  'CP'  ana  it  has  exactly  one  argument.  The  first  line  of  this  process 
is  therefore: 


EXTERNAL  PROCESS  CP  (NODE. NUMBER) 

which  agrees  with  ECSS  syntax.  DSS  will  append  to  the  name  'CP'  the  unique 
nodal  ID  number  so  as  to  create  a  unique  name  (and  therefore  a  unique  process, 
not  just  a  separate  instance)  for  each  of  the  nodes  in  the  simulated  network. 
DSS  will  also  activate  each  of  the  communication  processes  at  the  start  of  the 
simulation  and  pass  to  each  CP  process  its  unique  ID  number  through  its  one 
argument.  In  this  way  each  CP  process  will  have  access  to  its  own  ID  number. 
This  is  the  one  piece  of  information  OSS  provides  to  each  of  the  communication 
processes.  In  making  routing  decisions  it  is  necessary  for  a  communication 
process  to  have  a  local  variable  containing  its  own  ID  number. 

A  second  major  function  of  the  communication  process  is  to  coordinate  all 
activities  within  a  node.  It  is  the  executive  process  of  a  node.  It  performs 
the  initialization  functions  and  starts  the  jobs  and  processes  which  are  in 
the  Workload  Description  of  a  given  node  (Figure  2. 3. 2-2).  If  JOB. A  wants  to 
communicate  with  JOB.B  in  a  particular  node  it  must  first  SIGNAL  its  own  CP 
process,  pass  a  message  to  the  CP  process  by  the  mechanism  described  above, 
which  the  CP  process  then  passes  on  to  JOB.B.  JOB.B  will  communicate  with 
JOB. A  in  the  same  way. 
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Figure  2. 3. 2-2 
External  Process  CP 


The  CP  process  at  each  node  does  not  limit  the  ability  to  simulate  the 
functions  at  any  node  but  it  does  provide  a  structured  way  to  communicate 
between  nodes  and  also  among  jobs  and  processes  within  a  given  node. 

The  messages  in  OSS  which  are  passed  between  nodes  have  a  standard  format. 
Each  message  is  a  temporary  entity  with  certain  attributes  which  are  defined 
in  Table  2. 3. 2-3.  The  TYPE  attribute  is  used  in  cases  where  more  than  one 

kind  of  message  is  transmitted  between  nodes.  For  example,  a  TYPE  1  message 

might  signify  a  data  base  update;  a  TYPE  2  message,  a  data  base  query.  TYPE  2 
messages  would  require  a  response  from  the  destination  site;  a  TYPE  1  message 
might  not  generate  a  -  ‘oonse  and  after  the  update  has  been  completed  the 
message  could  be  destroyed.  The  communicating  process  for  a  node  has  the 
responsibility  of  interpreting  the  type  of  messages  which  arr-^ve  at  its  site 
and  taking  the  appropriate  action  -  such  as  starting  jobs  on  processors  - 
basec  on  this  and  other  information  contained  in  the  message. 

In  the  three  High  Level  models,  message  attributes  are  used  in  this  fashion. 
In  the  three  detail  models,  new  attributes  are  defined  as  required.  However, 
messages  (or  transactions  in  the  06  Model)  are  still  the  media  used  to 

activate  different  functions  in  the  CP  Process. 
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Message  Attributes 
Table  2. 3. 2-3 


TEMPORARY  ENTITIES 


EVERY 

..MSG 

1  HAS  AN  . 

.ID, 

MESSAGE  ID 

A 

..TYPE, 

"  MESSAGE  type 

A 

..PT, 

"  MESSAGE  POINTER 

A 

..LGTH, 

"  MESSAGE  length 

A 

..SRC, 

"  SOURCE  NODE  NUMBER  OF  MESSAGE 

A 

..DEST, 

"  DESTINATION  NODE  NUMBER  OF  MESSAGE 

A 

. .Cur, 

'  CURRENT  NOTE  NUMBER  OF  MESSAGE 

A 

..CR.TIME 

"  CREATION  TIME  OF  MESSAAGE 

A 

..NXT.NODE 

"  NEXT  NODE  NUMBER  MESSAGE  IS  GO  INI 

A 

..STAT, 

"  STATISTICAL  GROUP  OF  MESSAGE 

A 

..NPK, 

'  NUMBER  OF  PACKETS  IN  MESSAGE 

A 

..PKID, 

"  PACKET  ID  NUMBER 

A 

..Tl, 

'  T1,T2,T3,T4,  ARE  GENERAL  ATTRIBUTES 

A 

..T2, 

'  OF  MESSAGE 

A 

..T3, 

A 

..T4, 

A 

..PRTY, 

"  MESSAGE  PRIORITY 

A 

..Rl, 

R1,R2  ARE  GENERAL  ATTRIBUTES  OF 

A 

..R2, 

"  MESSAGE 

OWNS  A  ..HIST.Q, 

HISTORY  OF  MESSAGE  IS  CONTAINED 
AND  MAY  BELONG  TO  A  ..MGFILE 

THIS  SET 

DEFINE  ..CR.TIME,  ..LGTH,  ..Hi  AS  REAL  VARIABLES 

EVERY  ..HST.MSG  HAS  AN  ..NO. 

AN  ..ETIME, 

AND  BELONGS  TO  A  ..HIST.Q 
DEFINE  ..ETIME  AS  REAL  VARIABLES 


"NODAL 

"  IN 
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Eacn  (Tiessage  owns  a  set  called  HIST.Q.  ;^hen  a  message  enters  a  node  the  time 
of  its  arrival  along  with  the  nodal  identification  numoer  is  saved  in  th.- 
HIST.Q  set.  Tnis  standard  procedure  allows  OSS  to  trace  tne  route  a  messag'.- 
takes  through  the  communication  network.  It  is  also  a  device  for  collecting 

statistics  on  messages  such  as  average  delay  time  at  a  particular  node  for  a 

given  type  of  message. 

The  PT  attrioute  of  a  message  is  a  place  for  a  DSS  user  to  insert  a  pointer  to 
a  temporary  or  permanent  Simscript  entity.  Even  though  a  message  has  a  fixed 
format  in  DSS,  tnis  pointer  attribute  permits  complete  flexibility  in  the 
actual  amount  of  information  that  is  passed  from  node  to  node.  The  entity 

that  is  pointed  to  can  be  user  d^^ined  and  of  arbitrary  length.  For  example, 
in  a  very  detailed  simulation  the  user  defined  entity  could  be  the  actual 
header  for  MESSAGES  in  a  packet  switched  network.  It  should  be  emphasized 
that  wnen  message  transmission  is  simulated  only  a  pointer  to  a  message  is 

placed  in  the  message  file  of  a  node  since  this  is  the  only  information  that 
is  required  in  order  to  have  access  to  the  contents  of  the  message. 

2.4  DSS  INPUT  FILES  DESCRIPTION 

In  addition  to  a  library  of  DSS  models  DSS  requires  tnree  main  input  files; 

•  EXEC  File 

•  TP. FILE 

•  M.FILE 

The  content  and  format  for  each  of  these  files  is  discussed  in  the  following 
three  sections. 

2. a.]  EXEC  file  description 
Tne  EXEC  File  has  twc  purposes: 

1.  To  provide  a  means  for  specifying  the  dedicated  or  multiplexed  option 
for  interconnection  of  nodal  models; 

2.  To  provide  all  necessary  simulation  Defaults  on  the  model  specif;: 
level . 
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The  file  is  keyword  oriven  and  is  expandable  to  meet  user  requirements.  The 
format  of  the  EXEC  File  is: 


KW  OS 

where : 

KW  -  is  the  Keyword 

(alpha  characters; 

OS  -  option  selector 

(real  or  integer  value  depending  on  the  keyword  chosen) 


At  least  one  olank  between  tne  keyword  and  the  option  selector  is  required. 

The  only  keyword  in  the  EXEC  File  recognized  by  the  OSS  preprocessor  is 
"MLT".  The  value  of  the  option  selector  for  "MLT”  -  in  this  case  either  0  or 
1  -  determines  whether  internodal  transmission  devices  are  dedicated  or 

multiplexed.  The  fol  low4fv^section  describes  this  option  in  greater  detail. 
The  other  keywords  in  the  EXEC  File  are  model  specific  and  will  be  described 
in  the  sections  on  the  High  Level  Models  (Section  4)  or  the  Detailed  Models 
(Section  5). 


2. 4. 1.1  Multiplexed/Dedicated  Option 

The  difference  between  the  multiplexed  and  dedicated  options  is: 


Under  the  dedicated  option,  a  node 
it  has  paths  entering  or  leaving  wh 


will  have 
ch  connect 


as  many  transmission 
it  to  other  nodes. 


devices 


as 


Example  of  the  dedicated  option. 


dedicated 

devices 
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A  multiplexed  device  has  access  to  many  paths.  Under  the  multiplexed  option  a 
node  will  nave  only  one  internoaal  transmission  device  regardless  of  the 
number  of  paths. 


Example  of  the  multiplexed  option. 

mul riolexed 


The  user  may  select  tnis  option  {dedicated  or  multiplexed)  in  three  ways: 

1.  By  supplying  the  EXEC  file  with  a  "MLT"  as  the  keyword  and  a  "O'*  for 
the  option  selector,  the  device  configuration  will  be  dedicated. 

2.  By  supplying  the  EXEC  file  with  a  "MLT"  as  the  keyword  and  a  "1"  for 
the  option  selector,  the  device  configuration  will  be  multiplexed. 

3.  By  omitting  the  "MLT"  keyword  and  option  selector  from  the  EXEC  file 
the  device  configuration  will  default  to  the  deaicated  option. 

E X amp  1 e  use  of  this  file  is  as  follows: 

MLT  1  -  Multiplex#]  option 

MLT  0  -  Dedicated  option 


2.4,2  TP.FIlE  description 

Tne  TP. FILE'S  purpose  is  to  allow  the  user  to  generate  a  oe'^c-iption  of  the 
topological  interconnections  of  the  network  to  be  simulated. 


The  format  of  the  TP. FILE  consists  of  two  statement  types,  the  "SPD"  and  “NL" 
statements . 

The  format  for  the  "SPD"  statement  type  is: 

SPD  S 
where: 

SPD  -  is  the  keyword 

S  -  is  the  transmission  device  default  speed  (integer  value) 

The  format  for  the  "NL"  statement  type  is: 

NLI,S;JSD;JSD;... 

where: 

NL  -  is  the  keyword 

I  -  Key  node  (integer  value  -  required  input) 

J  -  Adjacent  node  (integer  value  -  required  input) 

S  -  Internodal  transmission  device  speed  (integer  value  -  optional) 

D  -  Delay  associated  with  the  path  between  node  I  and  J  (real  value  - 
optional ) 

The  first  statement,  "SPD",  assigns  the  default  speed  of  the  internodal 
transmission  device.  This  speed  is  used  by  the  DSS  for  the  devices  that  are 
defined  in  the  "NL"  statements.  A  new  default  speed  may  be  re-entered  at  any 
succeeding  line  in  the  TP. FILE  which  will  then  override  the  previous  default 
speed. 

The  second  statement,  "NL",  establishes  the  connection  between  the  nodes,  the 
internodal  transmission  device  speed  at  each  node  and  the  delay  associated 
with  the  path  between  the  nodes.  Device  transmission  speeds  are  optional  and 
will  default  to  the  current  "SPD"  value.  Path  delays  are  also  optional  in  the 
"NL"  statement  and  default  to  zero. 

All  inputs  in  the  TP. FILE  must  be  separated  by  at  least  one  blank.  Each  "NL" 
statement  is  limited  to  80  characters  and  cannot  be  continued  on  another 
line.  Examples  of  the  use  of  these  two  statements  follow. 
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Example  1  -  All  defaults  are  in  effect. 


SPO  25000 
NL  1  ;  2 
NL  3  ;  2  ;  4 

This  example  indicates  that  the  transmission  device  speed  is  25000  bytes/sec. 
The  EXEC  file  "MlT"  option  is  zero;  therefore  the  resulting  transmission 
device  configuration  is  dedicated.  The  result  from  this  TP. FILE  is  shown 
below. 

NETWORK  TOPOLOGY  FOR  EXAMPLE  1 


□  -  INTcRNODAL  transmission 
CEV ICE 

-  NODE 

Example  2  -  Complex  Configuration 
SPO  40000 

NL  6  ;  34000  1.0  ;  7  1.  5  ;  9  45000  2.0 

NL  7  ;  2  40000  .75  ;  8  50000 

SPO  75000 

NL  8  ;  3  25000  1.0  ;  9  28000  3.0 

NL  9  ;  4  18000  4.0  ;  5  2.4 

Tnis  example  illustrates  the  explicit  assigning  of  device  speeds  and  path 
delays. 

Tnis  example  also  shows  the  use  of  the  "SPO"  statement  to  change  the 
transmission  device  default  speed  from  40000  to  75000  bytes/sec. 
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The  EXEC  file  "MLT"  option  is  zero  and  therefore  the  resultitig  transmission 
device  configuration  is  dedicated.  The  following  figure  illustrates  this 
configuration; 


O 


NODE 


□ 


INTERNOOAL 
TRANSMISSION  DEVICE 

PATH 


2A83/11 
2.4.3  M.FILE  DESCRIPTION 

The  function  of  the  M.FILE  is  to  provide  the  relationship  between  the  node 
number  and  the  model  type  associated  with  that  node.  The  format  of  the  M.FILE 
is  as  follows: 


NN  MT 
where: 

NN  -  node  number  (Integer  value) 

MT  -  model  type  (Integer  value) 

At  least  one  blank  is  required  between  the  node  number  and  the  model  type. 
Examples  of  the  use  of  this  file  follow. 
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Example  1  -  Four  node  case. 


01  01 
02  02 
03  02 
04  01 

Nodes  1  and  4  are  of  model  type  1;  nodes  2  and  3  are  of  model  type  2. 

Example  2  -  Nine  node  case. 

1  01 
2  01 

3  01 

4  01 

5  01 

6  02 
7  02 
3  02 
9  02 

This  example  shows  that  nodes  1  thru  5  are  of  model  type  1  and  nodes  6  thru  9 
are  of  model  type  2. 

2.4.4  OSS  INTERNOOAL  TRANSMISSION  DEVICES  AND  PATHS 

DSS  offers  the  user  a  modular  approach  to  solving  network  simulation 
problems.  Each  node  of  a  network  may  be  simulated  with  a  structured  model. 
The  model'  are  joined  together  to  form  a  simulation  model  of  the  entire 
network. 

One  of  the  prime  functions  of  the  TP. FILE  and  M.FILE  is  to  provide  the 
necessary  information  to  the  DSS  Preprocessor  so  that  these  individual  models 
can  be  joined.  OSS  uses  the  information  contain  in  the  TP. FILE  and  M.FILE  to 
create  Internodal  Transmission  Devices  and  Paths  which  provide  the  ECSS  link 
between  the  individual  models. 
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All  Internodal  Transmission  Device  names  begin  with  a  "T".  Information  from 
the  TP. FILE  and  M.FILE  combine  to  construct  the  rest  of  the  name.  From  tne 
TP. FILE  the  node  number  is  taken.  From  the  M.FILE  the  associated  model  type 
is  secured.  DSS  maintains  a  count  of  all  Internodal  Transmission  Devices  as 
they  are  created  for  each  node.  As  a  device  is  created,  DSS  assigns  a  letter 
representing  its  occurence,  for  example,  "A"  =  First  Internodal  Device  for  the 
node,  “B"  the  second  etc..  For  each  nodal  pair  (e.g.,  NL  6  ;  1)  two 

Internodal  Transmission  Devices,  one  for  each  node  and  an  Internodal  Path 
linking  the  devices  are  created. 

I'nrerncjal  Paths  are  created  in  a  similar  fashion.  All  Internodal  Paths  begin 
with  an  "I".  Information  is  combined  from  the  TP. FILE  (node  number)  and  the 
M.FILE  (model  types  of  both  nodes  being  connected)  to  construct  the  Internodal 
Path  name.  DSS  also  maintains  a  count  of  the  number  of  Internodal  Paths 
created  at  eacn  node. 

Suppose  the  following  conditions  exist: 

The  user  desires  to  conhect  node  06  to  node  01.  The  following  TP. FILE 

statement  would  accomplish  this: 

NL  6  ;  1  TP. FILE  STATEMENT 

Also  tne  model  types  for  the  two  nodes  are  defined  in  the  M.FILE.  Suppose 

node  06  was  of  model  type  2  and  node  01  was  of  model  type  1,  the  M.FILE  would 

contain  the  following  information: 

M.FILE 

06  02 

The  following  illustration  (Figure  2. 4. 4-1)  graphically  displays  the 
information  required  to  create  internodal  devices  and  paths. 

In  the  above  example,  two  Internodal  Transmission  devices  called  T06A.M02  and 
TOlA.MOl  and  an  Internodal  Path  called  I06A. N06. NOl  are  created.  The  DSS 
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Preprocessor  uses  these  device  and  path  names  to  create  a  SPECIFY  statement, 
ana  a  PATH  statement,  whicn  connects  the  transmission  devices,  in  the  System 
Description  Section  of  an  ECSS  program.  For  example,  the  SPECIFY  statement 
that  OSS  generates  for  the  inter-nodal  devices  above  is: 

SPECIFY  1  T06A.M02  WHICH  TRANSFERS  MESSAGES  AT  40000  BYTES/SEC 

The  above  SPECIFY  statement  assumes  that  the  default  speed  for  the  Internodal 
Transmission  Device  is  40000  bytes/sec.  Should  the  "NL"  statement  connecting 
noce  06  to  node  01  contain  a  device  speed  of  34000  bytes/sec  for  node  01,  the 
resulting  SPECIFY  statement  would  be: 

SPECIFY  1  TOlA.MOl  WHICH  TRANSFERS  MESSAGES  AT  34000  BYTES/SEC 

The  devices  and  paths  that  DSS  creates  are  summarized  in  the  DSS  Topology 
Summary  Report.  Each  line  of  this  report  summarizes  the  devices  and  patn 
created  for  each  nodal  pair.  Below  is  an  example  of  a  line  from  that  report: 
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Sample  line  from  the  DSS  Topology  Summary  Report 


■06A.M02  40000  TOlA.MOl 

DEVICE  SPEED 
FOR  T06A.M02 


34000  I06A.N06.N01 


Loevice  speed 

FOR  TOlA.MOl 


1.0 

i 

PATH  DELAY 
ON  PATH 
I06A.N06.N01 


06  02  01  01 


CONNECTS 
NODE  06  TO 
NODE  01 


LINTERNOOAL  TRANSMISSION 
DEVICE  CREATE  FOR 
NODE  06 


INTERNOOAL  TRANSMISSION 
DEVICE  CREATED  FOR 
NODE  01 


INTERNOOAL  PATH 
CREATED  BY  DSS 
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To  summarize  the  DSS  creation  of  Internodal  Devices  and  Paths  Figure  2. 4. 4-2 
provides  a  capstone  illustration  of  the  DSS  Topology  Summary  Report, 


INPUTS: 
TP. FILE 


SPD  40000 

NL  6  ;  1  34000  1.0  ;  7  1.5  ;  9  45000  2.0 

NL  7  ;  2  40000  . 75  ;  8  50000  SPD  75000 

NL  8  ;  3  25000  1.0  ;  9  28000  3.0 

NL  9  ;  4  18000  4.0  ;  5  2.5 


M.FILE 
1  01 
2  01 

3  01 

4  01 

5  01  M.FILE 

6  02 

7  02 

8  02 
9  02 


EXEC  file 
WTTD  fxEC  file 


2.5  DSS  SIMULATION  OUTPUT 

As  messages  are  transmitted  from  one  node  to  the  next  in  a  OSS  Simulator, 
statistics  are  collected  and  a  report  is  generated  when  the  simulation 
te-minatas.  An  example  of  a  message  statistics  report  is  shown  in  Table 
2.5-1.  The  header  of  this  report  is  summarize  below. 


Type  defines  a  group  of  messages  upon  which  message  statistics  are 
gathered.  User  defined. 

Total  number  of  message  associated  with  each  message  type. 

The  time  required  for  a  message  to  traverse  the  network. 

Minimum  delay  time  for  each  message  type. 

Maximum  delay  time  for  each  message  type. 

Average  delay  time  for  all  messages  of  this  message  type. 

Standard  deviation  of  message  delay  time. 
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CONNECTS 


DEVICE 

DEVICE 

SPEED 

CREATED 

DEVICE 

SPEED 

PATH  CREATED 

PATH  DELAY 

NODE 

NO. 

MODEL 

TYPE 

NODE 

NO. 

MODEL 

TYPE 

TO0A.MO2 

£0000 

_T0lA.M0J_ 

_34000_ 

I06A.N06.N01 

^00005_ 

.  06_ 

02_  _ 

_01 _ 

_  _oi  _ 

T063.M02 

40000  _ 

_T07A.M02 

_40000_ 

I06B.N06.N07 

.00015 

.  06_ 

02_  _ 

_07 _ 

02 

T06C.M02 

40000  _ 

T09A.M02 

45000 

I06C.N06.N09 

4.0002  _ 

.  06_ 

02_  _ 

_09  _ 

_  _02  _ 

T073.M02 

4QQQ0 

T02A.MQ1 

40QQQ 

I07A.N07.N02 

.0001 

07 

02 _ 

_02 _ 

01 

T07:.^02 

40000  _ 

T.8A.M02 

_50000_ 

I07B.N07.N08 

.  07_ 

02_  _ 

_08  _ 

_  _02  _ 

T083.M02 

40000 

_T03A.M0J_ 

_25000__ 

I08A.N08.N03 

_^00005_ 

08_ 

02_  _ 

_03  _ 

_  _oi  _ 

T08:.M02 

40000  _ 

_T09B.M02 

_23000_ 

I08B.N08.N09 

4.0003  _ 

08_ 

02_  _ 

_09  _ 

_  _02  _ 

T09:.M02 

£8000  _ 

_T04A.M01 

_40000_ 

I09A.N09.N04 

4.0005  _ 

09_ 

02_  _ 

_04  _ 

_  _oi  _ 

T09D.M02 

ISOOO 

T05A.M01 

40000 

I09B.N09.N05 

.00035 

09 

02 

05 

01 

Figure  2. 4. 4-2  OSS  Topology  Summary  Report 
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In  addition,  DS5  collects  these  same  statistics  on  a  system  wide  basis  for  all 
messages. 

Message  characteristics,  such  as  message  length,  are  defined  in  the  MESS 
file.  For  each  type  of  message  defined  there  the  user  has  the  option  of 
specifying  what  statistics  gathering  group  (SGG)  it  belongs  to.  The  number 
following  the  "STT"  keyword  defines  the  group.  For  example,  three  typical 
lines  in  the  MESS  file  might  be: 

1  2  MML  30.  STT  1  ; 

1  3  MML  40.  STT  2  ; 

1  4  MML  50.  STT  1  ; 

In  this  example  the  messages  defined  in  lines  1  and  3  belong  to  the  same 
Statistical  Gathering  Group,  These  messages  will  be  treated  as  one  group  for 
statistics  gathering  purposes.  The  second  line  defines  a  second  SGG.  In  this 
way,  ()y  defining  an  arbitrary  number  of  SGG's,  the  user  can  decide  how 
detailed  the  report  generate^  should  be  in  collecting  separate  statistics  on 
sub-classes  of  messages  in  the  network.  The  user  must  specify  the  maximum 
number  of  SGG's  used  in  a  particular  run  by  using  the  NSG  Keyword  in  the  EXEC 
file.  The  default  is  tnat  only  system  wide  statistics  will  be  generated. 
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Table  2.5-1 

Message  Statistics  Report 


MESSAGE  STATISTICS 


NO.  OF  DELAY  TIME 


TYPE 

MESSAGES 

MIN 

MAX 

AVE 

STD 

1 

27 

3.70 

31.26 

17.43 

8.50 

2 

39 

2.70 

32.80 

14.64 

7.52 

3 

26 

1.70 

30.10 

15.75 

8.58 

4 

8 

1.40 

6.40 

4.00 

1.60 

5 

33 

i.7? 

24.11 

13.26 

6.76 

SYSTEM  -  WIDE 


NO.  OF 

DELAY  TIME 

MESSAGES 

MIN 

MAX 

AVE 

STD 

133 

1.40 

32.80 

14.44 

8.13 
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Since  DSS  programs  are  translated  into  ECSS  and  SIMSCRIPT.  all  of  the  ECSS 
statistics  gatnering  routines  and  report  generators  are  availaole  to  OSS. 
Since  eacn  node  in  the  network  simulator  has  its  own  unique  oevice,  path,  job 
and  process  names,  the  statistics  collected  from  the  simulator  are  quite 
detailed.  A  summary  of  these  reports  is  given  below.  (Refer  to  [f^^DE  76]  for 
a  complete  description). 

ALLUCATION  REPORT 

This  report  provides  utilization  statistics  as  well  as  average  and  maximum 
allocation  times  for  all  private  devices  at  every  node  in  the  simulator. 

ALLOCATION  QUEUE  REPORT 

Tnis  report  provides  all  of  the  queueing  statistics  associated  with  private 
devices  including: 

-  Total  number  of  requests 

-  Average  wait  for  allocation 

-  Total  enqueued 

-  Average  queue  length 

-  .Maximum  time  in  queue 

-  Percent  time  empty 

EXECUTION  REPORT 

The  Execution  Report  gives  the  percent  of  time  that  a  processor  device  was 
busy  by  specific  jobs  that  executed  on  that  device.  This  is  an  excellent  way 
to  determine  what  jobs  are  requiring  the  most  processor  time. 

PROCESSOR  utilization  REPORT 

This  report  gives  the  utilization  of  all  processors  in  the  network  as  well  as 
tne  number  of  activations  for  each  device  during  the  reporting  period. 

EXECUTION  (READY)  QUEUE  REPORT 

Tne  Execution  Queue  Report  displays  statistics  on  number  of  arrivals  to  a 
processor  and  all  of  the  queueing  statistics  including  average  and  maximu.m 
wait  for  service,  average  and  maximum  queue  length  and  percent  time  empty. 
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JOB  STORE  REPORT 

The  Job  Store  Report  shows  statistics  for  each  storage  device  on: 

-  Number  of  jobs  loaded 

-  Average  number  of  jobs  loaded 

-  Job  loaded  times 

-  Batch  capacity 

BATCH  JOS  STORE  QUEUE  REPORT 

For  all  storage  devices  in  the  network  this  report  provides: 

-  Total  number  of  requests  for  a  given  device 

-  Average  wait  for  loading 

-  Average  and  maximum  queue  lengths 

-  Percent  time  empty 

TRANSMISSION  PATH  REPORT 

The  Transmission  Path  Report  summarizes  how  busy  a  particular  path  was  for  t' e 
reporting  interval.  It  includes  the  total  number  of  transmissions  across  the 
path,  and  the  average  and  maximum  number  of  messages  transmitted  across  the 
path  at  any  one  time.  Also,  average  transmission  lengths  and  percentage 
utilization  are  reported. 

TRANSMISSION  PATH  QUEUE  REPORT 

This  report  provides  all  of  the  queueing  statistics  associated  with  any  path 
in  the  network.  It  includes: 

-  Total  number  of  requests  during  the  report  interval 

-  Average  wait  for  transmission 

-  Total  enqueued 

-  Average  queue  length 

-  Maximum  queue  length 

-  Average  and  maximum  time  in  queue 

-  Percent  time  empty 
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TRANSMISSION  REPORT 

Tnis  report  displays  statistics  on  the  amount  of  traffic  a  transmission  device 
handled.  Included  are  total  number  of  transmissions,  average  number  of 
transmissions,  transmission  capacity  and  the  average  and  maximum  transmission 
lengths.  The  percentage  of  the  transmission  capacity  used  during  the 
reporting  interval  is  also  provided. 

CRITICAL  DEVICE  TRANSMISSION  QUEUE  REPORT 

This  report  is  an  excellent  means  of  locating  bottlenecks  in  the  transmission 
medium  of  networks.  A  critical  device  on  a  path  is  the  device  which  causes  a 
message  to  be  enqueued  before  it  can  be  transmitted.  Any  device  which  is  a 
critical  device  by  this  criterion  at  any  time  during  the  simulation  is 
included  by  name  in  this  report.  Specifically,  this  report  includes; 

-  Device  name 

-  Total  enqueued 

-  Average  queue  length 

-  Maximum  queue  length 

-  Average  and  maximum  time  in  queue 

-  Percent  time  empty 

TRANSMISSION  RATE  REPORT 

The  transmission  rate  report  gives  the  total  number  of  messages  which  were 
transmitted  or  a  particular  device.  In  addition  it  gives  the  average 
cumulative  transmission  rate  for  a  device  during  the  reporting  intervals.  Tne 
Cumulative  rate  is  the  sum  of  the  rates  of  the  transmissions  occurring 
simultaneously  on  the  device.  The  average  and  maximum  transmission  rate  per 
message  is  provided  with  the  percent  idle  time. 

STORAGE  REPORT 

For  storage  devices  this  report  provides  these  statistics: 

-  Total  number  of  requests 

-  Average  and  maximum  storage  utilization 

-  Average  and  maximum  storage  request  size 

-  Storage  capacity 

-  Percentage  utilization 


00321 


2-43 


STORAGE  QUEUE  REPORT 

All  of  tne  queueinig  statistics  associated  with  storage  devices  are  summarized 
in  this  report.  These  include  total  requests,  average  wait  for  service, 
average  and  rnaximum  queue  lengths,  average  and  maximum  queue  times  and  percent 
time  empty. 

PROCESS/JOB  REPORT 

There  is  a  very  extensive  report  put  out  on  each  of  the  external  processes  and 
jobs  in  the  Workload  Description  section  for  each  of  the  nodes  in  the  network 
simulator.  This  report  includes,  by  process  or  job  name: 

-  Total  number  of  instances  of  the  process  or  job 

-  Number  of  completed  instances 

-  Average  instance  length 

-  Maximum  instance  length 

-  Total  length  of  instances 

-  Average  execution  time  per  instance  (Jobs  only) 

-  Maximum  execution  time  per  instance  (Jobs  only) 

-  Total  execution  time  per  instance  (Jobs  only) 

-  Average  transmission  time 

-  Maximum  transmission  time 


-  Total  transmission  time  per  instance 

-  A/erage 

time 

blocked 

for 

loading  (Jobs  only) 

-  Maximum 

time 

blocked 

for 

loading  (Jobs  only) 

-  Average 

time 

blocked 

for 

activation  (Jobs 

only) 

-  Maximum 

time 

blocked 

for 

activation  (Jobs 

only) 

-  Average 

time 

blocked 

for 

transmission 

-  Maximum 

time 

blocked 

for 

transmission 

-  Average 

time 

blocked 

for 

allocation 

-  Maximum 

time 

blocked 

for 

allocation 

-  Average 

time 

blocked 

for 

storage 

-  Maximum 

time 

blocked 

for 

storage 
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SECTION  3 

DEVELOPING  MODELS  OF  COMPUTER  NETWORKS 


3.1  GENERAL  METHODOLOGY 

The  purpose  of  this  section  is  to  provide. an  overview  and  introduction  to  the 
technical  approach  used  in  the  development  of  the  high  level  and  detailed 
level  computer  network  simulations. 

Before  all  major  design  concerns  can  be  identified,  one  of  the  most  important 
initial  considerations  must  be  what  types  of  analyses  the  models  are  going  to 
support.  It  is  necessary  to  understand  the  intended  use  of  a  simulation  model 
to  effectively  design  it.  The  way  a  model  is  to  be  used  or  the  types  of 
analyses  it  will  support  affect  the  level  of  detail  of  the  model,  what  aspects 
of  a  system  will  be  represented,  the  format  and  content  of  the  output  reports, 
and  the  inputs  required.  In  other  words,  the  purpose  of  a  simulator  is  to 
answer  certain  performance  and/or  cost-related  questions.  This  is  the  driving 
factor  in  simulator  design. 

Once  the  intended  use  has  been  defined,  a  first  approximation  can  be  made  as 
to  the  level  of  detail  that  should  be  incorporated  into  the  model.  From  past 
experience  with  models  of  computer  systems  and  networks,  a  continuum  of  detail 
levels  can  be  described.  Any  particular  model  is  just  one  point  on  that 
continuum.  What  s  important  is  to  provide  a  simulation  tool  that  has  the 
flexibility  to  easily  and  quickly  build  models  along  a  wide  portion  of  that 
spectrum.  This  is  necessary  because  it  is  not  always  possible  to  determine  a 
priori  the  appropriate  level  of  detail  to  answer  certain  questions.  For 
example,  a  system-level  model  may  contain  a  disk  subsystem  model  as  one 
component  (see  Figure  3.1-1).  Under  lightly  loaded  conditions  file  access 
time  may  be  adequately  represented  as  a  simple  delay.  However,  if  the  file 
transfer  times  in  this  model  are  short  compared  with  the  known  overhead 
involved,  such  as  disk  latency  times,  then  it  may  be  necessary  to  explicitly 
account  for  this  overhead.  That  is,  it  may  not  be  feasible  to  assume  one 
overall  transmission  delay  in  order  to  estimate  job  response  times  and  device 
utilizations  with  an  acceptable  degree  of  accuracy.  What  is  clearly  needed  is 
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WORKSTATION  MODEL  CPU  MODEL  FILE  SERVER  MODEL 


Figure  3.1-1  Three  views  of  a  Simulated  Computer  System 


a  simulation  tool  that  provides  the  user  with  an  effective  means  of  easily 
incorporating  different  levels  of  detail  within  a  model  to  help  solve  two 
related  classes  of  proolems: 


t  Sensitivity  analysis 

To  determine  those  critical  system  components  (ooth  nardware  ana 
software)  that,  when  varied,  have  a  significant  impact  on  the 
performance  of  the  system. 

•  Tradeoff  analysis 

To  estimate  the  accuracy  of  performance  measures  (e.g.,  throughput, 
response  times,  etc.),  given  certain  run  time  constraints  (and 
therefore  detail  level  constraints)  of  the  simulator. 

For  these  reasons,  it  is  unsatisfactory  to  have  a  simulation  tool  that  can 
moael  systems  along  a  narrow  band  in  the  spectrum  of  possible  detail  levels. 
In  addition,  computer  and  software  vendors  are  providing  new  products  on  a 
regular  basis.  Here  again  it  is  not  possible  to  predetermine  the  level  of 
model  detail  that  will  be  required  to  analyze  these  new  offerings. 

3.2  MODULARITY  AND  RECONFIGURABLE  SIMULATORS 

As  described  in  Section  2.3.1  OSS  allows  the  user  to  build  models  of  nodes  in 
a  system  and  save  each  model  separately  in  a  model  library. 

By  having  direct  correspondence  between  models  in  the  simulator  and  nodes  in 
the  simulated  system,  models  can  be  mixed  and  matched,  depending  on  the  type 
of  experiments  that  are  to  be  performed.  For  instance.  Figure  3.1-1  depicts 
three  nighly  simplified  views  of  a  simulated  computer  system.  Going  from  top 
to  oottom  in  this  figure,  more  detail  is  included  in  the  model.  There  is  a 
total  of  nine  models  stored  in  the  model  library;  a  workstation  model,  a  CPU 
model,  and  a  file  server  model  for  each  of  the  three  detail  levels.  Figure 
3.1-1  shows  only  the  increased  complexity  of  the  hardware  configuration;  there 
could  also  be  a  corresponding  increase  in  the  detail  of  the  resource  managers 
(operating  system  models)  and  in  the  workload  characterizations.  To  test  the 
sensitivity  of  the  file  access  mechanisms  on  the  job  throughput  rate,  the 
workstations  would  act  only  as  sources  and  sinks  for  generated  message  flows. 
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Then,  to  answer  questions  about  the  file  access  mechanism,  the  workstation 
model  and  processor  model  of  detail  level  one  and  the  file  server  model  of 
detail  level  three  could  be  used,  while  varying  the  file  access  methods.  To 
answer  other  types  of  questions,  the  simulator  can  be  reconfigured  in  a 
similar  manner. 

In  the  more  traditional  approach,  a  single  simulator  is  designed  and  built 
with  the  object  of  answering  all  of  the  questions  that  motivated  the 
simulation  study  at  the  outset.  Building  OSS  simulators,  we  can  be  more 
selective  in  our  approach.  The  simulator  can  be  reconfigured  depending  on  the 
requirements  of  a  particular  subset  of  the  proposed  experiments.  This  makes 
the  experimentation  stage  less  time-consuming  in  terms  of  run  time  costs,  and 
the  simulation  output  is  reduced  and  directly  applicable  to  the  questions  the 
experiments  were  designed  to  answer.  OSS  has  been  used  with  this  approach  in 
building  simulators  of  computer  networks.  The  key  to  this  approach  is  that 
OSS  supports  the  building  of  simulators  in  a  highly  modular  fashion.  As  can 
be  recalled  from  the  example  in  Section  2.2.5,  every  nodal  model  is 
constructed  from  three  basic  components  that  may  be  built  separately:  the 
System  Description,  Workload  Description,  and  Resource  Manager  sections.  Each 
nodal  model  is  built  separately,  but  may  be  connected  to  other  nodal  models  at 
a  later  time  to  form  one  large  network-wide  model.  This  structure  is  depicted 
in  Figure  3.2-1.  This  modular  construction  enables  the  user  to  move  easily 
from  one  level  of  detail  to  another.  For  example,  it  would  take  only  a  few 
minutes  to  describe,  using  the  model  language  of  Section  2.3,  the 
configurations  depicted  in  Figure  3.2-1. 

Similarly,  the  Workload  and  Resource  Manager  sections  can  be  created  or  used 
from  a  model  library.  In  this  way,  DSS  provides  reconf igurable  simulators 
based  on  the  modularity  of  its  design  approach. 

3.3  VERIFICATION,  VALIDATION.  AND  CALIBRATION 

When  developing  and  testing  models  of  computer  systems  and  networks, 
verification,  validation  and  calibration  are  three  essential  elements  in 
determining  the  usefulness  of  the  models.  These  processes  are  usually  done  on 
an  iterative  basis.  For  example,  in  modeling  the  job  arrival  process  to  a 
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computer  system  by  a  Poisson  process,  one  is  first  interested  in  whether  or 
not  the  simulator  is  generating  jobs  with  an  interarriva!  time  that  comes 
from  an  exponential  distribution  (verification).  Once  this  has  been 
established,  the  rate  of  the  Poisson  process  may  be  adjusted  to  agree  as 
closely  as  possible  with  the  rate  suggested  by  the  empirical  data 
(collected,  perhaps,  by  a  software  monitor);  this  is  the  calibration  stage. 
Finally,  validating  the  model  might  consist  of  checking  the  output  from  the 
simulator  against  a  range  of  data  collected  from  several  samples.  If  the 
agreement  is  not  satisfactory,  a  new  distribution  may  be  suggested  by  the 
data,  and  the  verification  process  would  begin  again.  Usually  with 
developed  simulation  tools  it  is  not  necessary  to  test  the  random  number 
generators  although  this  can  be  a  useful  exercise. 

The  design  of  USS  has  taken  into  account  the  verification,  validation  ana 
calibration  stages  of  simulators  by  providing  special  capabilities  for  the 
analyst  in  these  stages  of  model  development.  In  the  following  three 
sub-sections  we  describe  in  greater  detail  what  is  entailed  in  verification, 
validation  and  calibration  and  the  way  in  which  DSS  can  be  used  in  all  three 
stages. 

3.3.1  VERIFICATION 

In  this  initial  stage,  one  need  not  be  concerned  with  how  well  the  model 
represents  the  real  system;  the  principal  interest  is  in  the  ability  of  the 
simulator  to  represent  the  model  structure.  The  verification  process  used 
for  the  simulators  in  the  system-level  and  data-transfer-1evel  models  can  be 
outlined  in  four  steps. 

e  Internal  Consistency 

This  step  involves  checking  to  ensure  that  all  of  the  model  elements 
have  the  minimum  number  of  required  parameters;  that  allocated 
resources  are  later  deallocated  and,  in  general,  that  the  flow  of 
information  in  the  system  is  not  impeded  by  the  simulator  structure. 
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#  Exogenous  Variables 

This  step  in  the  verification  process  ensures  that  the  simulator  is 
driven  by  processes  and  loaning  parameters  that  are  consistent  witn 
the  model  design.  For  instance,  a  workload  description  that  does 
simulated  disk  reads  and  writes  is  not  appropriate  for  a  high-level 
model  whose  only  elements  are  switching  nodes  and  channels. 

#  Trace  reports 

There  are  two  classes  of  trace  reports  that  are  of  primary 
importance.  Simulator  programs  may  be  viewed  as  a  hierarchically 
structured  set  of  interacting  processes.  The  first  trace  facility 
allows  for  checking  that  the  intended  hierarchical  structure  is 
indeed  oeing  implemented:  only  certain  processes  may  initiate  other 
processes.  The  second  trace  facility  produces  a  detailed  listing  of 
elementary  operations  and  the  simulated  time  at  which  each  one 
occurred.  This  microscopic  view  of  the  simulator  can  be  turned  on 
and  off  when  desired  and  is  an  invaluable  aid  in  debugging  and 
verifying  simulators. 

#  Dump  Reports 

Simulator  programs  have  many  internally  defined  sets  and  tables  that 
are  usually  transparent  to  the  user.  For  instance,  there  is  a  global 
set  called  the  staging  list  for  jobs  that  are  waiting  for  execution 
time  on  simulated  processing  devices.  The  state  of  these  sets  and 
tables  may  be  interrogated  at  random  times  and  dumped  to  a  specified 
file  for  later  analysis.  A  dump  report  is  of  help  in  verifying  that 
the  simulator  is  performing  as  planned,  and  not  just  producing 
acceptable  results  because  of  a  peculiarity  in  the  loading  parameters 
or  system  description. 

3.3.2  AN  AID  TO  VERIFICATION:  THE  EVOLUTIONARY  APPROACH  TO  MODEL  DEVELOPMENT 
As  already  stated,  the  OSS  simulators  model  each  node  of  a  network 
separately,  and  the  nodal  models  are  combined  to  simulate  the  entire 
network.  Network  simulators  can  become  quite  complex  and  difficult  to  debug 
as  new  nodes  are  added.  The  ideal  situation  would  be  to  have  a  network 
simulator  grow  incrementally  as  new  nodes  are  added,  with  each  new  addition 
debugged  separately.  This  approacn  has  been  used  with  the  high  level  and 
detailed  level  simulators. 
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Three  high-level  models  of  networks  were  built  using  the  facilities  of  DSS. 
Table  3. 3. 2-1  summarizes  the  characteristics  of  each  of  these  models.  These 
models  are  of  packet-switched  (store-and-forward)  networks.  Going  from 
Model  1  to  Model  3  (see  Table  3. 3. 2-1)  the  architecture  of  a  node,  routing 
algorithms,  flow  control  procedures,  and  data  formats  become  more  detailed. 

The  purpose  of  this  section  is  not  to  go  into  the  particulars  of  each  one  of 
the  models,  but  to  describe  how  an  evolutionary  approach  to  model 
development  can  greatly  reduce  the  time  needed  to  build  and  verify 
5i''jl  ators. 

Three  levels  of  network  complexity  were  identified  for  each  one  of  the  high 
level  models.  In  level  A  (Figure  3. 3. 2-1),  the  simplest  network  is 
described:  a  two-node  network  in  which  one  host  communicates  directly  with 
another  host  site.  In  this  configuration,  only  one  model  from  the  DSS  model 
library  is  used,  since  the  nodes  are  identical.  Trace  output,  one  of  the 
most  effective  means  of  verifying  the  behavior  of  a  simulator,  can  be 
voluminous  for  a  multinode  network  simulator.  By  starting  with  very  simple 
configurations,  it  is  possible  to  take  very  detailed  looks  at  the  behavior 
of  tne  simulator  wnile  keeping  the  trace  output  to  a  manageable  level.  In 
complexity  level  B  (Figure  3. 3. 2-1),  a  switching  node  site  is  added.  This 
three-node  configuration  requires  two  models  from  the  DSS  model  library,  one 
for  the  switching  node  and  one  for  the  host  sites.  Again,  keeping  things  as 
simple  as  possible  increases  the  chances  of  detecting  problems  at  an  early 
stage.  The  third  level  of  complexity,  level  C  (Figure  3. 3. 2-1),  is  an 
arbitrary  network  configuration  using  the  verified  models  from  complexity 
levels  A  and  B.  The  changes  to  the  TP. FILE  and  M.FILE  are  quickly  made  when 
going  through  these  different  levels.  For  all  three  high-level  models,  this 
approach  to  model  development  was  instrumental  in  producing  completely 
debugged  simulators  by  the  time  complexity  level  C  is  reached. 

3.3.3  CALIBRATION/VALIOATION 

After  a  simulator  has  been  verified,  a  set  of  validation  experiments  is 


00321 


3-8 


carefully  designed  to  determine  whether  or  not  tne  model,  which  is 
implemented  by  the  simulator,  conforms  co  expectations.  If  the  agreement  is 
not  good,  the  parameters  or  the  structure  of  the  model  is  manipulated  and 
the  resulting  output  data  are  again  compared  with  independently  generated 
historical  data.  This  procedure,  calibration  of  a  model,  is  continued  until 
the  model  and  historical  data  agree  within  a  predetermined  tolerance.  This 
procedure,  however,  does  not  necessarily  produce  a  valid  model  since  it  may 
only  be  representative  of  a  particular  set  of  input  data.  A  successfully 
calibrated  model  must  then  be  compared  with  other  sets  of  historical  data  to 
ensure  that  the  model  is  sufficiently  general  to  be  a  predictor  of  behavior 
across  a  broad  range  of  input  data. 


Table  3. 3. 2-1  Summary  of  Key  Model  Characteristics 


CHARACTERISTICS 

HIGH-LEVEL 

MODEL  1 

HIGH-LEVEL 

MODEL  2 

HIGH-LEVEL 

MODEL  3 

MODEL 

ARCHITECTURE 

•  PROCESSOR 

•  INTERNODAL 
TRANSMISSION 
DEVICES 

•  PROCESSOR 

•  CHANNELS 

•  TERMINALS 

•  BUFFERS 

•  INTERNODAL 
TRANSMISSION 
DEVICES 

•  PROCESSOR 

•  CHANNELS 

•  TERMINALS 

•  BUFFERS 

•  INTERNODAL 
TRANSMISSION 
DEVICES 

ROUTING 

FIXED 

FIXED 

NONDETERMINISTIC 

ADAPTIVE 

DATA  FORMAT 

MESSAGE 

PACKET 

PACKET 

FLOW  CONTROL 

NO 

YES 

. 

YES 

MESSAGE 

I  INTER  ARRIVAL 

TIME 

CONSTANT 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  OIST. 

-  EXPONENTIAL  DIST. 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  DIST. 

-  EXPONENTIAL  OIST. 

MESSAGE 

LENGTH 

CONSTANT 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  DIST. 

-  EXPONENTIAL  DIST. 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  DIST. 

-  EXPONENTIAL  DIST. 
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Figure  3. 3. 2-1  Complexity  Levels 

A.  Complexity  Level  A  -  Host  to  Host  Configuration 

B.  Complexity  Level  B  -  Host/Switch/Host  Configuration 

C.  Complexity  Level  C  -  Arbitrary  Configuration 


V 


Below  is  an  outline  of  some  of  the  steps  in  the  validation  and  calibration 
process  for  computer  network  simulations. 

•  Simplified  Workload  Description 

In  this  step,  the  loading  factors  are  minimized  to  include  only  one 
or  a  very  few  jobs.  By  simplifying  the  workload  description,  it  is 
possible  in  many  instances  to  determine  quite  accurately  what  the 
expected  values  of  the  performance  measures  should  be.  The 
complication  of  resource  contention  is  practically  nullified,  and  the 
job  flow  can  usually  be  more  easily  determined.  Characteristics  of 
the  models  not  load  dependent  can  be  validated  in  this  step. 

•  Deterministic  Models 

Some  models  may  be  more  easily  analyzed  and  performance  measures 
calculated  if  the  random  variates  that  determine  key  parameters  of 
the  system,  such  as  interarrival  times,  are  assumed  to  be 
deterministic.  This  step  may  be  used  with  the  simplified  workload 
description  to  validate  soine  of  the  performance  measures  of  the 

simulator.  For  example,  routing  protocols  may  be  validated  in  this 

way,  since  they  do  not  depend  on  the  distribution  of  job  interarrival 
times,  but  on  the  congestion  and  availability  of  switching  nodes. 

•  Analytic  Models 

Analytic  models  can  provide  an  independent  source  of  performance 
measures.  For  instance,  a  communication  network  in  the  high-level 

model  may  be  simulated  as  a  set  of  nodes  (switching  computers)  and 
connected  by  high-speed  channels.  Assuming  the  service  ates  of  the 
nodes  and  channels  are  exponentially  distributed  with  a  Poisson 

stream  of  jobs  as  input  to  designated  nodes,  this  system  can  be 
modeled  as  a  Markovian  network  of  queues  and  servers.  This  allows 
derivation  of  performance  measures,  such  as  utilization  and  message 
response  time,  independently  of  the  simulator.  These  measures  may 
then  be  used  to  validate  the  simulator.  Analytic  models,  when  they 
are  mathematically  tractable,  will  be  used  in  the  proposed  validation 
experiments . 
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•  Hypothesis  Testing 

Certain  systems  have  known  or  expected  behavior  characteristics  that 
can  be  tested  using  the  simulator.  This  expected  behavior  may  be 
known  in  only  a  qualitative  sense.  For  instance,  it  might  be 
determined  that  utilization  of  specified  resources  cannot  be  improved 
in  a  certain  system  due  to  capacity  constraints.  Another 
quantitative  hypothesis  might  be  that,  as  throughput  increases, 
response  time  is  degraded.  These  hypotheses,  even  though  they  cannot 
be  stated  precisely  in  quantitative  terms,  can  be  tested  using  the 
simulator.  If  there  is  disagreement  between  the  hypotheses  and  the 
simulator  output,  either  the  fault  in  the  simulator  must  be  corrected 
or  an  explanation  of  why  a  hypothesis  is  false  must  be  found. 
Usually  in  this  stage  other  subsidiary  hypotheses  concerning  the 
behavior  of  the  system  are  suggested,  which  can  be  checked  in  turn  by 
the  simulator. 

•  Independent  Random  Number  Generation 

In  analyzing  the  output  from  a  simulator  during  the 
calibration/validation  phases  we  are  interested  in  the  true 
performance  measures  of  the  modelled  system  independently  of  the 
noise  generated  by  using  a  particular  random  number  stream. 
Simscript  II. 5  provides  ten  starting  seeds  for  this  purpose.  This 
allows  for  greater  flexibility  in  the  design  of  experiments  and 
reduces  the  cost  of  simulation  runs  without  reducing  the  usefulness 
of  the  results.  In  representing  ranoom  processes  in  a  model,  it  is 
important  to  be  able  to  isolate  various  processes.  For  example,  in  a 
simple  queuing  system,  one  expects  that  the  arrival  distribution 
should  be  independent  of  the  service  mechanism.  If  we  are  limited  to 
one  sequence  of  random  numbers,  it  would  be  difficult  to  represent 
this  independence.  (It  could  be  done,  to  a  degree,  with  very  long 
runs.)  However,  by  assigning  different  random  number  streams  to  the 
two  processes  and  thereby  starting  from  different  values,  we  can  have 
the  desired  independence.  Further,  from  an  experimental  design  point 
of  view,  we  can  more  quickly  demonstrate  the  effects  of  a  change  in 
value  of  a  controlled  variable.  For  example,  if  we  change  the  number 
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of  servers  In  our  simple  queueing  system  and  repeat  the  experiment 
with  the  same  starting  seeds  for  each  stream,  then,  through  careful 
implementation  of  the  model,  we  can  show  that  any  changes  in  the 
results  from  the  simulations  are  the  direct  result  of  the  changes  in 
the  controlled  variable  (number  of  servers)  and  not  due  to  random 
variations.  [RUSS  82]. 

Since  there  is  literally  an  unlimited  number  of  models  that  can  be 
implemented  using  the  simulators  for  the  high  level  and  detailed  level 
models,  only  a  subset  of  these  possibilities  can  be  tested.  However,  the 
number  of  different  types  of  elements  in  these  simulators  is  finite  and  well 
defined.  For  instance,  there  are  computing  resources  and  input  devices  in 
the  high  level  model.  All  of  the  elements  have  been  tested  by  applying 
different  loading  factors  over  a  broad  spectrum  of  values  to  ensure  that  the 
utilization  of  the  system  resources  goes  from  lightly  loaded  to  nearly  100 
percent  of  their  capacity.  The  library  routines  that  implement  standard 
resource  managers,  communication  protocols,  etc.  have  also  been  tested  in 
this  way. 

The  models  that  have  been  developed  are  documented  in  the  order  of 
increasing  complexity,  and  the  loading  factors  applied  to  them  are  described 
to  ensure  that  all  combinations  of  model  elements  have  been  verified. 
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SECTION  4 

HIGH  LEVEL  MODELS  OF  COMPUTER  NETWORKS 


4.1  INTRODUCTION 

In  Section  4  each  of  the  High  Level  Models  (HLM)  is  descrioed  -  the  input 
files  that  are  required,  the  architecture  and  functional  flow  of  each  model 
and  the  output  generated  by  each  mocel. 

HLM  #1  simulates  a  message  switched  network.  Messages  are  generated  at  host 
or  use''  sites,  routed  through  tne  network  by  a  deterministic,  routing 
algorithm  and  finally  destroyed  at  the  destination  site.  HLM  ttZ  has  all  of 
the  facilities  of  HLM  #1.  In  addition,  it  incorporates  two  types  of  flow 
control  procedures  to  control  congestion  within  the  network.  The  model 
architecture  explicitly  represents  input/output  devices  at  the  host  sites 
and  buffer  sizes  at  every  node  in  the  network.  Also,  messages  may  be  broken 
into  packets  and  routed  through  the  network  in  this  format.  HLM  #3  is 
similar  to  HLM  #2.  However,  HLM  #3  simulates  adaptive  routing  procedures 

through  a  non-deterministic  routing  table.  See  Table  4.1-1  for  a  summary  of 

these  differences.  Statistics  representing  message  delays,  resource 
utilization,  bottlenecks  in  the  system,  queueing  etc.  are  collected  and 
reports  generated  for  each  node  in  the  network. 

As  we  move  from  HLM  #1  to  HLM  #3  the  complexity  of  the  models  increases, 
which  requires  more  detailed  input  data  from  the  user.  The  models  are 

upwardly  compatible.  For  example  the  routing  table  for  HLM  #1  may  be  used 
as  an  input  file  to  HLM  #3.  By  providing  a  range  of  models  of  increasing 
complexity  the  network  designer  is  not  constrained  to  inputting  model 
parameters  at  only  one  level  of  detail.  For  instance,  buffer  size  is  a 

required  input  for  HLM  #2.  If  this  data  is  not  available  the  designer  may 
use  HLM  #1  where  this  does  not  play  a  factor  in  the  model  inputs. 
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Table  4.1-1  Summary  of  Key  Moael  Characteristics 


I 


CHARACTERISTICS 

HIGH  LEVEL 

MODEL  1 

HIGH  LEVEL 

MODEL  2 

HIGH  LEVEL 

MODEL  3 

••'ODEL 

.ARCHITECTURE 

•  PROCESSOR 
«  INTER NODAL 
TRANSMISSION 
DEVICES 

•  PROCESSOR 

•  CHANNELS 

•  TERMINALS 
t  BUFFERS 

•  INTERNODAL 
TRANSMISSION 
DEVICES 

•  PROCESSOR 

•  CHANNELS 

•  TERMINALS 

•  BUFFERS 

•  INTERNODAL 
TRANSMISSION 
DEVICES 

ROUTING 

FIXED 

FIXED 

NON-OETERMINIST 

ADAPTIVE 

DATA  FORMAT 

MESSAGE 

PACKET 

PACKET 

FLOW  CONTROL 

NO 

YES 

YES 

MESSAGE 

INTERARRIVAL 

TIME  (MIT) 

CONSTANT 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  OIST. 

-  EXPONENTIAL  OIST. 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  DIST. 

-  EXPONENTIAL  OIST. 

MESSAGE 

LENGTH  (,MML) 

CONSTANT 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  DIST. 

-  EXPONENTIAL  DIST. 

CONSTANT  OR 
STOCHASTIC  PROCESS 

-  UNIFORM  DIST. 

-  EXPONENTIAL  DIST. 

4.2  MODEL  SPECIFIC  INPUT  FILES 

Several  model  specific  input  files  are  required  to  run  ECSS  simulations.  They 
are: 


•  The  EXEC  file  which  provides  the  defaults  required  for  the  simulation, 

•  The  ROUT  file  which  provides  the  routing  table  for  the  simulation  and 

•  The  MESS  file  which  defines  all  message  characteristics. 

The  format  of  these  input  files  are  designed  to  be  upwardly  compatible  so  as 
to  require  little  or  no  alternations  when  running  any  of  the  high  level 
models.  For  example,  the  ROUT  file  used  for  High  Level  Model  1  can  be  used 
without  any  changes  when  running  High  Level  Model  3. 

The  dashed  box  in  Figure  4.2-1  identifies  the  Model  Specific  Input  files. 
These  files  are  detailed  in  the  OSS  User's  Manual. 

4.3  HIGH  LEVEL  MODEL  1 

High  Level  Model  1  simulates  a  message  switching  network.  Messages  are  routed 
through  the  network  by  a  deterministic,  fixed  routing  algorithm.  This  model 
contains  no  flow  control  procedures  in  that  when  a  message  is  transmitted  it 
will  always  be  accepted  by  the  receiving  node. 

4.3.1  MODEL  ARCHITECTURE 

High  Level  Model  1  requires  two  DSS  model  types: 

■  A  model  to  describe  the  behavior  of  the  host  sites  and 

•  A  model  to  describe  the  behavior  of  the  switching  nodes. 

The  association  between  the  model  type  and  node  number  is  defined  in  the 
M.FILE. 


4.3.1 .1  Host  Sites 

The  function  of  the  host  site  is  to  generate  new  messages  and  destroy  messages 
sent  from  other  host  nodes.  Each  host  site  consists  of: 

f  A  processor; 
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less 

SIMULA iOR 


Figure  4.2-1  Model  Specific  Input  Files 


•  A  variable  number  of  internodal  transmission  devices.  The  number  of 
devices  will  vary  depending  on  whether  the  option  is  multiplexed  or 
dedicated  channels.  The  example  shown  in  Figure  4. 3. 1.1-1  is 

dedicated.  Therefore,  there  will  be  as  many  internodal  transmission 

devices  as  there  are  paths  entering  or  leaving  each  node. 

Figure  4. 3. 1.1-1  shows  the  host  site  configuration. 


INTERNODAL 

TRANSMISSION 

DEVICE 


OUTGOING 

MESSAGES 


Figure  4. 3. 1.1-1  Host  Site  Configuration 

The  specifications  describing  the  Processor,  located  at  each  host  site,  are 
defined  in  the  OSS  Model  Library.  To  change  these  specifications  the  user 
must  change  the  OSS  Model. 

The  Internodal  Transmission  Oevice  specifications  are  parameterized  directly 
through  the  TP. FILE.  Table  4. 3. 1.1-1  summarizes  the  System  Description  for  a 
typical  nost  site. 

4. 3. 1.2  Switching  Nodes 

The  function  of  the  switching  node  is  to  accept  and  forward  messages  along  the 
network.  Each  switching  node  consists  of: 

•  A  processor 

t  A  variable  number  of  Internodal  Transmission  Devices.  Refer  to  Host 
description 

Figure  4. 3. 1.2-1  is  a  representation  of  a  switching  node. 
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TaDle  4. 3. 1.1-1  System  Description  for  Host  Site 


DEVICE 

NAME 

ECSS 

DEVICE 

TYPE 

PERFORMANCE 

SPECIFICATIONS 

OOIA.CPU 

EXECUTION  AND 

(Processor) 

JOB  STORE  DEVICE 

500000  INSTRUCTIONS/SEC 

1 

TClrt.MOl 

( Internodal 

TRANSMISSION 

15000  BYTES/SEC 

Transmission 

DEVICE 

Device) 

INCOMING^ 

MESSAGES^ 


TRANSMISSION 

DEVICES 


OUTGOING^ 

MESSAGES 


Figure  4, 3. 1.2-1  Switching  Node  Configuration 


Specifications  describing  the  processor  are  again  defined  in  the  OSS  Model 
Library.  The  specifications  related  to  the  Internodal  Transmission  devices 
are  defined  in  the  TP. FILE.  Table  4. 3. 1.2-1  summarizes  the  system  description 
for  a  typical  switching  node.  The  table  also  shows  the  internodal  path 
connecting  two  internodal  transmission  devices  from  node  1  and  node  2. 
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Table  4. 3. 1.2-1  System  Description  for  Switching  Node 


DEVICE 

NAME 

ECSS 

DEVICE  TYPE 

PERFORMANCE 

SPECIFICATIONS 

D02A.CPU 

EXECUTION  AND 

(Processor) 

JOB  STORE  DEVICE 

400000  INSTRUCTIONS/SEC 

T02A.M02 

( Internodal 

TRANSMISSION 

Transmission 

1  Devce) 

DEVICE 

10000  BYTES/SEC 

POIA.NOI .N02 

PATH 

CONNECTS  TOlA.MOl 

( Internodal ) 

to  T02A.M02 

4,3.2  FUNCTIONAL  LOGIC  FLOW 

High  Level  Model  1  simulates  a  forward  switching  network.  Host  sites  generate 
and  forward  messages  to  a  switching  node.  Switching  nodes  accept  and  forward 
messages  to  either  another  switching  node  or  to  a  host  site.  Passing  messages 
between  switching  nodes  may  require  several  transfers  depending  on  the 
topology  of  the  network.  Finally,  the  final  destination  host  site  accepts  the 
message,  updates  the  message  statistics  and  destroys  the  message.  Figure 
4. 3. 2-1  is  a  functional  flow  diagram  of  this  process.  Two  major  external 
processes  provide  the  control  functions  (eg.,  message  generation  and  starting 
computer  jobs)  for  High  Level  Model  1.  They  are: 

•  ..ARR  process  (message  generation)  and 

•  CP  Process  (communication  process  -  controlling  computer  jobs) 

A  brief  description  of  each  process  is  provided: 
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(1) 


MESSAGES 
GENERATED 
AT  HOST  SITE 


'  (2) 

MESSAGES 

FOR'WARDED  TO 
SWITCHING  NODE 

BY  DETERMINIS¬ 
TIC  ROUTING 
ALGORITHM 

• 

— 

r 

_ (3) 

SWITCHING  NODE 
ACCEPTS  AND 

FORWARDS  MESSAGE 

BY  DETERMINIS¬ 
TIC  ROUTING 
ALGORITHM 

• 

•  ROUTINE  RD.MSG.AR  AND  EXTERNAL  PROCESS 
•ARR  COMBINE  TO  ACCOMPLISH  THIS  TASK 


•  ECSS  JOB  JU  PROVIDES  THIS  FUNCTION 


•  MAY  REQUIRE  SEVERAL  MESSAGE  TRANSFER 
DEPENDING  ON  NETWORK  TOPOLOGY. 

#  ECSS  JOB  JW  ACCOMPLISHES  THIS  TASK 


HOST  NODE 
ACCEPTS  MES¬ 
SAGE  UPDATE 
STATISTICS 
AND  DESTROY 
MESSAGE 


J 


ECSS  JOB  JT  PROVIDES  THIS  FUNCTION 


Figure  4. 3. 2-1  Functional  Logic  Flow  of  High  Level  Model  1 
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Message  Generation  -  External  Process  ..ARR 

The  ,.ARR  process  provides  the  vehicle  for  generating  every  message  introduced 
into  the  networK.  This  process  simply  cycles  according  to  the  interarrival 

rate  (MIT)  estaplished  in  the  MESS  file  or  defaulted  in  the  EXEC  file. 

Messages  are  created  each  time  the  process  cycles.  The  number  of  instances  of 
..ARK  in  the  External  Process  Reports  indicates  the  number  of  different 
message  types  generated  during  the  'imulation  run. 

Communication  Process  -  External  Process  CP 

’’he  orirrary  function  of  the  communication  process  is  to  control  the 

tOTVTani  cation  between  nodes.  A  conmunication  process  may  start  jobs  on  a 

processing  unit  whicn  simulates  the  activity  of  transferring,  switching  and 
receiving  messages.  Statistics  on  these  external  processes  are  displayed  on 
the  External  Process  Report.  The  number  of  instances  for  the  CP  processes 
should  be  one.  These  processes  are  started  only  once  and  continue  to  operate 
for  the  full  duration  of  the  simulation. 

The  communication  process  activates  and  controls  three  computer  joos: 

t  COB  OU 

•  JOB  JW 

•  JOB  JT 

A  destription  of  these  jobs  is  provided. 

JOB  JU  -  Message  Transferring 

JOB  JU  simulates  the  activity  of  transferring  a  message  from  a  host  site  to  a 
switching  node.  It  accomplishes  this  task  by  filing  the  pointer  to  the 
message  (MSG)  data  in  the  switching  nodes  message  file  (..MGFILE).  The  JOB 
concludes  by  signaling  the  switching  node.  This  notifies  the  communication 
process  that  it  has  a  message  waiting  for  it.  The  total  number  of  instances 
for  JOB  JU  can  be  interpreted  as  the  total  number  of  messages  transmitted  from 
JU’s  host  site. 
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JOB  JW  -  '-lessaqe  Swi  telling 

Message  switching  is  accomplished  by  activating  JOB  JW.  This  job  is  identical 
in  ^unction  and  logic  to  job  JU  except  it  is  initiated  in  the  communication 

process  of  a  swi*-ching  node.  The  total  number  of  instances  for  JOB  JW  can  be 

interpreted  as  the  total  number  of  messages  switched  at  JW's  switching  node. 

JOB  JT  -  Message  Receiving 

Messages  are  received  by  activating  JOB  JT.  When  a  message  arrives  at  its 

final  destination,  the  host  communication  process  invokes  the  message 

receiving  JOB  JT.  This  job  calls  two  routines. 

•  Routine  ..TOT  -  which  updates  the  message  statistics  and 

•  Routine  ..DM  -  which  destroys  the  message. 

The  total  number  of  instances  for  JOB  JT  can  be  interpreted  as  the  total 
number  of  messages  received  at  JT-s  host  site.  Refer  to  the  OSS  User's  Manual 
for  more  information  relating  to  Job/External  Process  reports. 

4.3.3  SIMULATOR  OUTPUT 

Tne  OSS  Simulator  produces  two  output  reports: 

$  Message  Statistics 

•  ECSS  Standard  Reports 

For  a  description  of  each  report  contained  in  this  section  refer  to  Section 
2.4  of  the  User's  Manual.  For  a  complete  sample  of  these  reports  refer  to 
Appendix  A  -  Level  C.  Examples  of  these  reports  follow: 
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MESSAGE  :.TATISTIC  REPORT 


NO.  OF  DELAY  TIME 


TYPE 

MESSAGES 

MIN 

MAX 

AVE 

STD 

1 

27 

3.70 

31.26 

17.43 

8.50 

2 

39 

2.70 

32.80 

14.64 

7.52 

3 

26 

1 .70 

30.10 

15.75 

8.58 

4 

8 

1.40 

6.40 

4.00 

1.60 

5 

33 

1.71 

24.11 

13.26 

6.76 

SYSTEM  -  WIDE 

NO.  OF 

DELAY  TIME 

MESSAGES 

MIN  MAX 

AVE 

STD 

133  1.40  32.80  14.44  8.13 


Refer  to  Section  2.4  for  Report  Description 
Refer  to  Appendix  A  -  Level  C  for  output  sample 

EXECUTION  REPORT 
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EXAMPLES  OF  THE  EXECUTION  REPORTS  -  FOR  DESCRIPTION  OF  EACH  REPORT,  REFER  TO  SECTION  2.4. 


JOB  STORE  REPORT 
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EXAMPLI.S  OF  IRANSMISSION  REPORTS  -  FOR  A  DESCRIPTION  FOR  EACH  REPORT,  REFER  TO  SECTION  2.4. 
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JOB  REPORT  FOR  JWA 


EXAMPLES  Of  JOB/fWCESS  REPORTS  -  FOR  A  DESCRIPTION  OF  THESE  REPORTS,  REFER  TO  SECTION  2.4. 


4.4  HIGH  LEVEL  MODEL  2 

High  Level  Model  2  differs  from  High  Level  Model  1  in  five  major  ways: 

1.  The  model  implements  two  forms  of  flow  control  procedures. 

2.  Messages  are  generated  and  terminated  at  input/output  devices. 

3.  Messages  are  divided  into  packets  before  they  are  transmitted  through 
the  network. 

4.  Buffer  space  is  explicitly  modeled. 

5.  Packets  are  reassembled  into  messages  at  host  sites. 

4.4.1  MODEL  ARCHITECTURE 

High  Level  Model  2  consists  of  two  model  types: 

e  A  model  to  describe  the  behavior  of  the  host  sites  and 

•  A  model  to  describe  the  behavior  of  the  switching  nodes. 

4. 4. 1.1  Host  Sites 

Each  Host  site  consists  of: 

•  A  processor 

•  A  variable  number  of  internodal  transmission  devices  (refer  to  High 
Level  Model  1) 

•  10  I/O  devices 

•  2  Channels 

•  1  Buffer 


Figure  4. 4. 1.1-1  illustrates  the  Host  Site  Configuration. 


Figure  4. 4. 1.1-1  Host  Site  Configuration 
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The  njmber  of  I/O  devices  and  channels  can  be  changed  in  the  DSS  High  Level 
Model  2  host  model.  The  Internodal  device  specifications  are  defined  in  the 
TP. file.  Buffer  specifications  are  changeable  through  the  EXEC  file  and  the 
System  Description  Section  of  tne  host  model.  The  System  Description 
specifications  for  the  host  site  are  summarized  in  Table  4. 4. 1.1-1. 

4. 4. 1.2  Switching  Nodes 
Each  switching  node  consists  of: 


•  A  Processor 

•  A  variable  number  of  Internodal  Transmission  devices  (Refer  to  Section 
4. 3. 1.2  Switching  Nodes  High  Level  Model  1). 

•  A  Buffer 

Figure  4. 4. 1.2-1  is  a  representation  of  such  a  switching  node. 


BUFFER 


ARRIVING  . 

V 

MESSAGE 

2S 

PROCESSOR 


2A83/6 


OUTGOING  . 

M 

MESSAGE 

INTERNODAL 

TRANSMISSION 

DEVICES 


Figure  4. 4. 1.2-1  Switching  Node  Configuration  (Dedicated  Option) 


The  Processor  and  Buffer  declarations  are  provided  in  the  DSS  Switching 
Model.  The  specifications  for  the  Internodal  Transmission  devices  are  defined 
in  the  TP. FILE.  Table  4. 4. 1.2-1  provides  a  summary  for  the  System  Description 
Section  for  the  switching  node. 
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Table  4. 4. 1.1-1  System  Description  for  Host  Site 


DEVICE 

,MAME 

ECSS 

DEVICE  TYPE 

PERFORMANCE 

SPECIFICATIONS 

I 

DOIA.CPU 

(Processor) 

executions  ANDS 

JOB  STORE  DEVICE 

500,000  INSTRUCTIONS/SEC 

T01A.M01 

( Internodal 

Transmission 

Ce/ice) 

TRANSMISSION 

DEVICE 

20,000  BYTES/SEC 

0016.  CHANNELS 

(Channel ) 

TRANSMISSION 

DEVICE 

2,000,000  BYTES/SEC 

DOID.BUF 

(Buffer) 

1 

STORAGE 

DEVICE 

10,000  BYTES 

001 C. TERMINAL 
'  ' Termi na 1 ) 

1 

I/O 

DEVICE 

9600  BYTES/SEC 

POIA.T.PATH 

(Internodal  Path) 

PATH 

CONNECT  DOIB.  CHANNELS 

TO  001 C  TERMINALS 

i 
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Table  4. 4. 1.2-1  System  Description  for  Switching  Node 


ECSS 

DEVICE 

TYPE 

PERFORMANCE 

SPECIFICATIONS 

D02A.CPU 

EXECUTION  AND 

(Processor) 

JOB  STORE  DEVICE 

500,000  INSTRUCTIONS/SEC 

TQ2A.MC1 

( Inte-TOdal 

TRANSMISSION 

30,000  BYTES/SEC 

Trans  ni ss ion 

DEVICE 

pevice j 

D02B.BUF 

STORAGE 

(Buffer) 

DEVICE 

10,000  BYTES 

POIA.NOI .N02 

PATH 

CONNECTS  TOlA.MOl 

(Internodal  Path) 

TO  T02A.M02 

4.4.2  FUNCTIUNAL  LUGIC  FlUW 

High  Level  Model  2  simulates  a  score  and  forward  pacKet  switching  network. 

This  model  incorporates  packet  switching  and  flow  control  procedures. 

Flow  control  procedures  are  implementeo  oy  both  the  host  ana  switching  nodes. 

These  techniques  include: 

•  In  the  host  site  three  limits  are  sec  by  the  user,  they  include; 

-  The  upper  limit  (MM3)  on  the  number  of  unacknowledged  packets  that 
may  be  transmitted  from  a  host  site  to  the  communication  network. 
This  limit  is  specified  in  the  EXEC  file. 

-  The  upper  limit  (MM2)  on  the  number  of  messages  that  can  be 
assembled  at  any  moment.  This  limit  is  specified  in  the  EXEC  file. 

-  The  actual  buffer  size  (BFH)  at  the  host  site.  This  value  is  set  in 
the  EXEC  file. 

«  In  the  switching  node  two  limits  are  set  by  the  user.  They  include: 

-  The  upper  limit  (MMl)  on  the  number  of  packets  at  a  switching  node 
waiting  to  be  transferred  or  acknowledged.  This  limit  is  set  in  the 
EXEC  file. 

-  The  buffer  size  (BFC)  at  the  switching  node.  This  limit  is  also  set 
in  the  EXEC  file. 

There  are  three  major  functional  flow  logic  areas  within  High  Level  Model  2. 

They  are: 

•  Host  site  message  initiation  logic 

a  Host  site  message  reassembly  logic 

t  Switching  node  packet  handling  logic 
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Tne  nost  site  message  initiation  logic  is  displayed  in  Figure  4. 4. 2-1. 
Messages  are  generated  at  the  terminal.  The  messages  are  divided  into  packets 
according  to  a  user  specified  size  (PKZ)  and  filed  in  the  input  queue. 
Packets  may  be  assigned  a  priority  (PTY).  The  lowest  assignable  priority  is  a 
"0".  A  packet's  priority  defaults  to  zero  if  no  default  is  defined.  The  MESS 
file  for  High  Level  Model  1  can  be  used  for  High  Level  Model  2  if  the  packet 
size  (PKZ)  specified  by  tne  user  is  equal  to  a  constant  message  length  (MML). 
In  this  way,  the  MESS  file  is  upwardly  compatible. 

The  communication  process  verifies  that  the  upper  limit  on  the  number  of 
unacknowledged  packets  (MM3)  that  may  be  transmitted  has  not  been  reached.  If 
this  limit  has  been  reached,  tne  packet  is  denied  transmission  and  forced  to 
wait  until  an  acknowledgement  for  one  of  the  outstanding  packets  is  received. 
If  the  limit  has  not  been  reached  the  packet  is  allowed  to  be  transmitted.  An 
acknowledgement  of  a  user  specified  length  (AKL)  from  the  receiving  node 
indicates  a  successful  transfer  of  the  packet.  If  the  host  does  not  receive 
this  acknowledgement  within  a  user  specified  time  (TMH),  it  retransmits  the 
packet.  This  cycle  of  waiting  and  retransmitting  continues  until  a  successful 
transfer  is  accomplished. 

The  host  site  message  reasembly  logic  is  illustrated  in  Figure  4.4. 2-2. 
Packets  arrive  from  adjacent  n  to  be  reassembled  at  the  destination  host 
site.  Upon  arrival  two  limiting  factors,  the  reassembly  buffer  size  (BFC)  and 
the  number  of  messages  being  reassembled  simultaneously  (MM2),  are  checked. 
If  either  factor  exceeds  its  user  defined  limit  the  arriving  packet  is  ignored 
and  the  acknowledgement  to  the  sender  node  is  aborted.  If  neither  of  the 
limits  is  exceeded,  the  communicaton  process  accepts  the  packet,  allocates 
buffer  space  and  sends  to  the  forwarding  node  an  acknowledgment  of  the 
packet's  arrival.  A  check  is  made  to  determine  if  this  packet  is  the  last 
packet  missing  from  the  reassembled  message.  If  it  is,  the  reassembled 
message  is  sent  to  the  terminals  and  the  allocated  buffer  space  is  released. 
If  more  packets  are  required,  the  arriving  packet  is  stored  until  all  of  the 
packets  required  to  reassemble  the  message  arrive.  Single  packet  messages  are 
sent  directly  to  an  I/O  device  and  no  reassembly  buffer  space  is  allocated. 
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Figure  4. 4. 2-2  Host  Site  Message  Reassemble  Logic 


The  switching  node  packet  handling  logic  is  illustrated  in  Figure  4. 4. 2-3. 
Switching  nodes  accept  packets  from  adjacent  nodes  ana  forward  these  packets 
to  another  switching  node  or  a  host  site.  However,  the  acceptance  of  the 
packet  is  predicated  on  two  limiting  factors; 

•  available  buffer  storage  (BFC)  and 

•  the  number  of  packets  currently  at  the  switching  node  (MMl). 

If  either  of  these  user  defined  limits  are  exceeded,  the  switching  node  simply 
ignores  the  packet  and  does  not  send  an  acknowledgement  to  the  sending  node. 
If  neither  of  the  limits  are  exceeded  the  switching  node  sends  an 
acknowledgement  to  the  sending  node  ana  transmits  tne  packet  to  its  next 
destination.  The  communication  process  retransmits  the  packet  if  it  does  not 
receive  an  acknowledgement  within  a  user-specified  time  (Ti'iC). 

The  communication  process  for  High  Level  Model  2  provides  the  same  type  of 
functions  as  the  communication  process  for  High  Level  Model  1. 

In  addition  to  activating  the  many  computer  jobs,  this  communication  process 
accomplishes  the  following: 

1.  Breaks  messages  into  packets  according  to  a  user  specified  size  (PKZ), 

2.  Allocates  buffer  space, 

3.  Monitors  unacknowledged  messages, 

4.  Initiates  the  retransmit  process  for  all  unacknowledged  packets, 

5.  Provides  total  control  on  all  packet  transmissions;  internodal  and 
intranodal . 

Jobs  required  to  implement  packet  switching  and  flow  control  are  described 
below: 

•  JOB  JA  -  Job  JA  simulates  the  transmission  of  a  packet  from  the  I/O 

device  to  the  CPU  processor.  The  number  of  instances  of  this 
Job  indicates  the  number  of  packets  originating  from  the  host 
site  which  utilize  JOB  JA. 
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Figure  4. 4. 2-3  Switching  Node 
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-  >^08  JC  simulates  the  transmission  of  a  packet  along  an  Internodal 

Path.  The  number  of  instances  of  this  Job  would  indicate  how  many 
packets  were  injected  into  the  network  at  a  particular  node. 

JU  -  JOB  JU  retransmits  the  packet  if  an  acknowledgement  has  not  been 

received  within  a  user  specified  time.  Tne  number  of  instances  of 
JOB  JU  indicates  the  number  of  packets  sent  from  a  particular  node 
which  were  rejected  by  an  adjacent  node. 

JQ8  AK  -  JOB  AK  is  responsible  for  sending  acknowledgements  for  accepted 

packets.  This  job  is  only  operational  when  a  ''1"  is  indicated  for 
"ACK"  in  the  EXEC  file.  The  number  of  instances  of  JOB  AK  indicates 
the  number  of  packets  accepted  oy  a  particular  node. 

JOB  JU  -  JOB  JO  simulates  the  receiving  and  the  acceptance  of 

acknowledgements  from  adjacent  nooes.  The  number  of  instances  of 

this  JOB  indicates  the  number  of  acknowledgements  received  from 
adjacent  nodes. 

JOB  JB  -  JOB  JB  simulates  the  transmission  of  a  completely  reassembled 

message  from  the  CPU  processor  to  the  I/O  devices.  The  number  of 
instances  of  JOB  J8  indicates  the  total  number  of  completely 

reassembled  messages  at  a  host  node. 

JOB  PC  -  JOB  PC  is  tne  timing  mechanism  that  schedules  the  retransmit  command 
for  all  unacknowledged  packets.  The  user  specifies  the  frequency 
with  which  this  job  is  performed  by  selecting  the  maximum  response 
time  tolerable  for  all  acknowledgements  at  the  host  (TMH)  and 
switching  nodes  (TMC).  The  number  of  instance  of  this  job  indicates 
how  many  times  a  particular  node  assessed  the  status  of  its  outgoing 
packets. 

4.4,3  SIMULATOR  OUTPUT 

Tne  same  type  of  reports  are  generated  by  OSS  as  are  produced  for  High  Level 

Model  1.  Complete  descriptions  of  these  reports  are  provided  in  the  DSS 

User ' s  Manual . 
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MESSAGES  STATISTICS 


TYPE 

NO.  OF 

MESSAGES 

MIN 

DELAY  TIME 

MAX 

AVE 

STD 

1 

208 

1.08 

2.17 

1.60 

.39 

2 

208 

1.08 

2.36 

1.69 

.37 

3 

163 

.38 

.64 

.44 

.07 

4 

200 

,38 

,78 

.46 

.08 

SYSTEM  -  WIDE 

NO.  OF 

DELAY  TIME 

MESSAGES 

MIN 

MAX 

AVE 

STD 

784 

.38 

2.36 

1 .08 

.66 

Message  Statistics  Report  -  For  A  complete  Description  of  The  Report 

Refer  to  Section  2.4 
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EXECUIION  REPORT  -  FOR  A  COMPLETE  DESCRIPTION  OF  THESE  REPORTS.  REFER  TO  SECTION  2.4. 
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STORAGE  REPORT  -  FOR  A  COMPLETE  DESCRIPTION  OF  THESE  REPORTS,  REFER  TO  SECTION  2.4. 


4.5  HIGH  LEVEL  MODEL  3 

High  Level  Model  3  is  different  from  High  Level  Moael  2  in  that  it  uses  a 
non-deterministic  routing  table.  The  "C”  level  example  of  this  model 
illustrates  the  upward  compatibility  of  the  053  input  files.  For  example,  tne 
simulation  model  for  Level  C  consists  of  several  files  from  Hign  Level  Model  1 
and  2.  No  new  files  are  required. 

4.6.1  ADAPTIVE  ROUTING 

Routing  algorithms  may  generally  be  classified  as  either  fixed  or  adaptive. 
ititT  fixed  routing  algoritnms  the  next  node  to  which  to  send  a  message  • 

pre-determined.  In  adaptive  routing  the  procedure  to  foi'ward  packets  is 
sensitive  to  the  changing  state  of  the  network.  They  are  generally  variants 
of  shortest  path  algorithms  that  route  packets  from  a  source  node  to  a 
destination  over  a  path  of  least  cost.  The  specific  cost  function  used  in  a 
particular  network  may  vary  widely.  Some  costs  are  functions  of  channel 
capacity,  link  or  transmission  line  capacity,  number  of  hops  from  source  to 
destination,  error  rates  over  given  paths,  expected  queue  lengths  at  various 
nodes  and  so  on.  Beside  these  differences  in  link  cost  functions,  routing 
techniques  tend  to  differ  in  implementation  ana  the  place  at  which  the 

algorithms  are  run.  They  may  be  actually  located  in  a  single  node  or  the 

decision  making  functions  may  be  dispersed  throughout  the  network.  How 

frequently  the  routing  tables  are  updated,  routing  decision  overhead  and  the 
numbe''  of  parameters  the  adaptive  procedures  are  sensitive  to  are  also 

distinguishing  characteristics.  However,  a  high  level  view  of  these  adaptive 
techniques  suggests  these  overriding  characteristics:  multiple  paths  may  exist 
from  source  to  destination  and  these  paths  change  over  time.  That  is,  a 

message  going  from  node  A  to  node  B  might  go  by  way  of  path  X  at  time  T  and  by 

path  Y  at  a  later  time.  If  measured  over  time  a  certain  percentage  of  the 
total  number  of  messages  going  from  A  to  B  will  choose  path  X  over  path  Y.  It 

is  this  average  behavior  that  is  approximated  by  a  new  type  of  routing  table 
that  is  incorporated  in  HLM  #3. 

4.5.2  SIMULATOR  OUTPUT 

OSS  produces  the  same  type  of  reports  for  High  Level  Model  3  as  it  provides 

for  High  Level  Models  1  and  2.  Refer  to  the  OSS  User's  Manual  for  a  complete 

description  of  each  report.  For  complete  examples  of  each  report  refer  to 
Appendix  C. 
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MESSAGES  STATISTICS 


NO.  OF  DELAY  TIME 


TYPE 

MESSAGES 

MIN 

MAX 

AVE 

STD 

1 

199 

.08 

.28 

.16 

.08 

2 

188 

.09 

.13 

.12 

.08 

3 

165 

.06 

.22 

.10 

.06 

4 

40 

.17 

.22 

.19 

.02 

5 

133 

.08 

.15 

.09 

.02 

SYSTEM  -  WIDE 

NO.  OF 

DELAY  TIME 

MESSAGES 

MIN 

MAX 

AVE 

STD 

720 

.06 

.28 

.12 

.06 

Message  Statistics  Report  -  For  A  complete  Description  of  The  Report 

Refer  to  Section  2.4 


00321 


4-37 


EXECUTION  REPORT 


£  8  I 

fsrf 

^ 

9'  O'  O' 


XX  fsj  ^ 

$ 


uJ  »  O  ^  Y 

Co  'O 

^  O  —  rx^  (M 

O 
UJ  (/) 


3  cd 

» 
O'  < 


O  9  «- 

o  5  S 


z  “i 


s 

& 


§  f  R 

O  CD 
—  rsi  f«g 

o  o  o 


K 

O 


^  —  iTi 
fX«.  » 
rx4  ^ 
—  K»  rxj 

8  8  8 


O 

X  ^ 


2  S 


£ 

o 


=  2  S  S  f 

»  8  S  8  S 


t 

; 

—  <  <  < 

»  ^  (M 

8  8  8  8 


00321 


4-38 


EXECUTION  REPORTS  -  FOR  A  COMPLETE  DESCRIPTION  OF  THESE  REPORTS.  REFER  TO  SECTION  2.4. 
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DETAILED  MODELS  OF  COMPUTED  DETWOkKL 


5.1  OVERVIEl^ 

This  section  gives  a  summary  description  of  the  design  and  rationale  for  each 
of  the  Detailed  Models  for  Phase  II  of  the  RADC  DDP  Topology  Evaluation 
Project.  (Succeeding  sections  descrioe  eacn  of  these  models  at  greater 
length. ) 

The  three  detailed  models  for  phase  II  are: 

•  Communication  Protocol  (CP)  Detailed  Model 

•  Rel  i  api 1 i ty/Avai 1 aPi 1 i ty  (R/A)  Detailed  Model 

•  DistriPuted  OataPase  (08)  Detailed  Model 

We  have  been  concerned  during  both  phases  of  the  DDP  project  with  two  primary 
tasks: 

Ij  Development  of  high  level  (Phase  I)  and  detailed  level  (Phase  II) 
models  of  distributed  data  processing  systems  that  would  have  wide 
appl icabi 1 ity; 

2)  Development  of  a  modeling  tool  which  would  facilitate  the  building  of 
simulators  that  could  be  put  into  an  expandable  model  library  for 
later  use  and  enhancement.  This  tool  is  called  DSS. 

In  light  of  these  two  primary  tasks,  the  design  and  rationale  for  the  detailed 
models  must  serve  the  functions  outlined  above.  In  particular,  DSS  should  be 
able  to  model  OOP  Systems  incorporating  a  great  deal  of  variability  in  the 
level  of  detail  required.  As  a  reference  point  the  International  Standards 
O'-gar ization's  (ISO)  seven  layer  architectural  design  was  used.  The  highest 
level  is  tne  application  level  wnich  includes  distributed  data  base  management 
systems  (D08M),  The  lowest  layer  of  the  ISO  Model  that  has  any  significant 
impact  on  performance  is  the  data  link  layer.  (DSS  incorporates  a  propagation 
delay  factor  where  that  is  appropriate,  for  instance  satellite  links  or  long 


lines,  wnich  is  on  the  physical  layer.)  Accoraingly,  we  chose  two  mooels  that 
incorporate  either  end  of  the  ISO  Reference'  Mode'l:  the  06  System  .Model  roi- 
tnea.jp h cat  1  on  level  and  the  LP  Model  for  the  data  link  layer.  Each  ot  these 
models  incorporates  all  of  the  seven  layers  of  the  ISO  Reference  Model  (for 
example,  eacn  contains  a  routing  mechanism  which  is  part  of  the  network  layer) 
but  special  attention  is  paid  to  the  application  layer  in  the  06  Model  and  the 
data  linK  layer  in  the  CP  Model.  Figure  5.1-1  illustrates  the  ISO  Keterence 
Model's  layered  Network  Architecture. 

But  tnis  is  only  one  of  the  reasons  for  having  a  06  Model  and  CP  Model.  The 
I ange  of  applicability  is  also  important.  One  of  the  most  important 
applications  in  distributed  data  processing  technology  is  DDBM  Systems. 
Almost  any  computer  network  will  incorporate  a  DDBM  System.  Therefore  a  DOBM 
Model  is  an  important  test  for  evaluatir  the  capabilities  of  DSS. 

One  of  the  most  fundamental  ways  in  which  a  distributed  system  differs  from 
the  traditional  centralized  systems  is  in  tne  area  of  communication 
protocols.  DSS  may  be  viewed  as  an  extension  of  ECSS.  ECSS  was  designed  oy 
the  Rand  Corporation  in  1975  to  make  the  modeling  of  centralized  systems 
easier.  DSS  uses  ECSS  as  a  building  block  and  adds,  among  other  things,  an 
Inter-nodal  Communication  Facility.  This  facility,  along  with  the  ECSS 
transmission  manager,  allows  the  user  to  model  communication  protocols 
effectively  and  easily.  Because  communication  protocols  are  so  important  to 
the  performance  of  computer  networks  and  because  modeling  this  aspect  of  DDP 
Systems  goes  beyond  the  traditional  world  view  of  ECSS  we  have  chosen  to 
include  the  CP  Model.  The  particular  communication  protocol  that  has  been 
modeled  is  the  X.25  interface  for  packet  switched  networks  which  includes  the 
High  Level  Data  Link  Control  (HDLC)  protocol  on  the  data  link  level  of  the  ISO 
Model.  This  is  the  most  widely  used  communication  protocol  and  has  been 
adopted  by  several  international  organizations,  including  ISO,  and  nationally 
by  A.NSI. 

The  Reliability/Availability  (R/A)  Model  is  included  for  several  reasons.  One 
of  the  main  rationales  for  the  development  of  DDP  technology  is  the  increase 
in  the  reliability/availability  of  the  system  that  can  be  realized  from  a  well 
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Figure  5.1-1  ISO  reference  Model 


designea  network.  Therefore,  OSS  should  be  capable  of  modeling  such  a 
design,  '-^e  concluded,  therefore,  that  a  separate  R/A  simulator  which  modeled 
only  reliability  and  availability  would  be  a  meaningless  abstraction:  The 
Model  should  be  embedded  in  a  realistic  model  of  a  total  OOP  System  so  thatth-.' 
design  choices  inherent  in  the  system  coulo  be  evaluated  as  to  their  impact  on 
reliability/availability.  Further,  the  R/A  modeling  techniques  that  we  have 
Chosen  should  be  transportable  to  any  functioning  simulator  of  a  DDP  system. 
The  R/A  Model  has  been  designed  to  meet  these  two  criteria  (i.e.,  it  must  be 
embedded  in  a  total  system  model  and  not  be  separate  from  it;  and  secondly, 
the  techniques  must  be  easily  transportable  to  other  simulators).  We  have 
Chosen  to  embed  the  R/A  Model  in  the  communication  protocol  model  since 
different  protocols  can  have  an  enormous  impact  on  the 
rel  1  abi  1  i  ty/avai  1  abi  1  i ty  of  the  entire  system.  In  fact,  one  of  the  major 
functions  of  a  communication  protocol  is  to  correct  and  recover  from 

transmission  failures  and  nodal  downtime.  Therefore  a  R/A  Model  in  thi-, 
context  would  be  particularly  appropriate. 

5.1.1  COMMUNICATION  PROTOCOL  (CP)  DETAILED  MODEL 

Communication  protocols  are  a  relatively  new  area  for  simulation  and  modeling 
due  to  the  advent  of  distributed  processing  technology.  Communication 
protocols  may  be  considered  the  operating  system  for  networks.  For  OSS 
(Distributed  System  Simulator)  to  be  useful  in  modeling  networks  it  must  be 
able  to  simulate  communication  at  a  detailed  level.  Network  performance  is 
significantly  affected  by  the  communication  protocols  that  the  network  is 

using.  User  response  time  and  throughput  depend  on  the  efficiency  (degree  or 
overneac)  of  the  protocols.  OSS,  in  order  to  be  a  practical  tool,  must 

facilitate  tne  modeling  of  communication  protocols.  The  most  widely  used 
communication  protocol  is  the  International  Standards  Organization's  (ISO) 

High-Level  Data  Link  Control  (HOLC).  The  CP  Model  is  a  DSS  detailed  Model  of 
HDLC  and  the  X.Z5  interface  which  includes  the  following  components: 
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t  Number  of  Bits  in  an  ACK  Frame 

•  Number  of  Data  Bits  per  Framt- 

•  Interrupt  the  Processor  Service  Time 

•  Sender's  Window  Size 

•  Receiver's  Window  Size 

•  Negative  Acknowledgement  Frames 

•  Receive  Ready  Frames 

5.1.2  reliabilitv/availability  (r/a)  detailed  model 

Increased  reliability/availability  is  one  of  the  most  attractive  features  of 
distributed  processing  technology.  Because  a  well  designed  network  is  a 
gracefully  degradable  system,  traditional  reliability  models  are  not 
applicable.  Reliability/availability  is  a  function  of  a  broad  range  of 
network  characteristics,  including  hardware  and  system  software  components. 
Because  of  this,  the  R/A  Detailed  Model  has  been  designed  as  a  general  model 
that  can  be  used  in  a  wide  variety  of  environments  -  from  distributed  data 
base  models  (layer  7  of  the  ISO  Reference  Model)  to  data  link  control  models 
(layer  2  of  the  ISO  Reference  Model).  We  have  chosen  to  embed  the  R/A 
detailed  model  in  the  communication  protocol  model,  though  the  routines  and 
techniques  used  are  just  as  applicable  to  any  of  the  other  detailed  models. 
The  R/A  detailed  model  includes  these  components: 

«  System  Avai lability 

•  System  Reliability 

•  Failure  Control 

t  Effects  of  Down  Time 

•  Failure  Recovery  Rates 

•  Effects  of  Transmission  Errors 

•  Effects  of  Lost  Messages 


Tie  importance  of  the  R/A  detailed  model  stems  from  the  fact  that  reliability 
and  availability  as  performance  issues  cut  across  all  boundaries  and  affect 
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all  types  of  networks  no  matter  what  particular  applications  the  networks  are 
servicing.  This  is  why  the  R/A  detailed  model  has  the  broadest  possible  scope 
in  terms  of  the  general  approach  that  it  incorporates. 

5.1.3  DISTRIBUTED  DATABASE  (DB)  DETAILED  MODEL 

Distributed  data  bases  are  one  of  the  most  common  application  areas  for 
distributed  processing  technology.  There  are  several  advantages  to  DDbM 
systems.  As  processor  and  memory  costs  are  reduced,  communication  costs  are 
becoming  a  larger  percentage  of  the  data  processing  budgets  of  many 
organizations.  Local  data  bases,  whicn  can  nevertheless  be  accessed  from 
remote  locations,  reduce  communication  costs.  Another  advantage  of  DDBM 
systems  is  reliability.  A  particular  site  which  is  experiencing  difficulties 
need  not  cause  the  entire  network  to  fail. 

A  third  advantage  is  that  networks  allow  for  incremental  growth  without 
restructuring  the  entire  system.  The  performance  characteristics  of  a  DDBM 
system  are  dependent  on  many  factors.  Simulation  models  can  help  in  the 
analyses  that  are  necessary  to  design  a  cost-effective  system  that  meets 
certain  performance  requirements.  The  DDBM  System  Model  includes  these 
components; 

•  Transaction  Updates/Modifications 

•  Transaction  Retrievals 

•  Number  of  Lockups 

•  Concurrency  Control 

•  File  Allocation 

t  Transaction  Rates 

•  Transaction  Overhead 

•  Processor  Utilization 

•  Buffer  Utilization 

•  Average  Queue  Lengths  at  File  Servers 

•  Delays  Due  to  Blocking/Synchronization 

•  Transaction  Throughput 

•  Transaction  Response  Time 


00321 


5-6 


The  funciional  :haracLeristics  of  cne  moael  are  such  that  the  user  .tiay  vary  a 
wide  range  of  DDBM  system  parameters  and  study  the  effects  in  terms  of  the 
resource  utilizations  (channels,  p^'ocessors,  buffers,  transmission  paths)  and 
tne  net  user  effect  (throughputs,  response  times). 

5.2  COMMUNICATION  PRUTQCQL  MUQEL 

Tne  Communication  Protocol  Model  simulates  tne  X.25  interface  for  packet 
switched  service.  Two  new  mechanisms  -  virtual  circuits  and  datagrams  are 
introduced  in  this  model. 

5.2.1  THE  X.25  INTERFACE  RECOMMENDATION 

Tne  X.25  Interface  is  the  standard  device  independent  interface  between  packet 
networks  and  user  devices  operating  in  packet  mode.  The  X.25  Interface  was 
recommended  by  the  International  Telegraph  and  Telephone  Consultative 
Committee  (CCITT)  in  1976  to  estaolish  an  international  standard  for  public 
data  networks.  The  X.25  interface  recommendation  at  the  packet  level  defines 
tie  following  services: 

1)  Permanent  virtual  circuits  (PVC); 

2)  Switched  virtual  circuits  (SVC);  and 

3)  Datagrams. 

A  permanent  virtual  circuit  is  a  permanent  association  between  two  nodes, 
which  is  analogous  to  a  point-to-point  private  line.  Call  setup  or  call 
clearing  procedures  are  not  required  for  a  permanent  virtual  circuit.  This 
: /oe  cf  virtual  circuit  was  simulated  in  High  Level  Model  2  and  is  not 
i-^cluded  in  the  Communication  Protocol  model.  A  switched  virtual  circuit 
(SVC)  creates  a  temporary  association  between  an  originating  node  and  a  target 
node.  Tne  node  initiates  a  'call  request'  to  the  networK  containing  the 
address  of  the  target  node.  A  switched  virtual  circuit  is  estaolished  when 
tne  target  node  accepts  the  'call  request'  and  issues  a  'call  accepted'  to  the 
originator.  Once  the  SVC  has  been  established,  the  virtual  circuit  becomes  a 
bidirectional,  transparent,  flow-controlled  path  between  a  pair  of  logical  or 


00321 


5-7 


pnysical  ports.  Packets  can  now  be  sent  from  the  originator  to  target.  Once 
all  packets  have  been  received,  a  'call  clear'  is  sent  from  the  target  node  to 
the  originator  node.  The  'call  clear',  upon  receipt  at  the  originator, 
releases  the  temporary  SVC. 

The  major  benefit  of  SVC  is  the  reduced  overhead  when  exchanging  large  amounts 
of  data  packets  periodically  with  a  variety  of  target  nodes.  When  short  units 
of  data  need  to  be  exchanged  frequently,  the  overhead  of  SVC  becomes 
significant  compared  to  the  amount  of  data  being  transferred.  With  small 
amounts  of  data  the  datagram  can  be  more  efficiently  used.  The  datagram  can 
oe  described  as: 

1)  A  self-contained  message  with  a  unique  identifier,  originator  node  and 
target  node  information, 

2)  Usually  delivered  intact,  most  often  implemented  as  a  single  packet 
message, 

3)  Having  a  high  probability  of  being  delivered  to  the  desired 
destination,  however  it  can  also  be  lost  due  to  transmission  errors  or 
netwoi'k  problems, 

4)  The  sequence  of  datagrams  is  not  maintained, 

5)  Some  form  of  error  recovery  for  non-del ivered  datagrams  is  provided. 
[FOLT  30,  RYBC  80]. 

This  section  of  the  User's  Manual  will  focus  on  both  SVC  and  datagrams  as 
implemented  in  the  Communication  Protocol  Model. 

5.2.2  DATA  FLOW  DIAGRAMS 

A  Data  Flow  of  a  datagram  traveling  through  a  network  is  graphically  portrayed 
in  Figure  5. 2. 2-1.  The  more  complex  case  of  a  Switched  Virtual  Circuit  is 
aisplayed  in  Figure  5.2. 2-2. 
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5.2.3  MODEL  ARCHITECTURE 

The  Communication  Protocol  Model  consists  of  two  model  types: 

•  A  model  to  describe  the  behavior  of  the  host  sites  and 

•  A  model  to  describe  tne  benavior  of  "-wicching  nodes. 

5. 2. 3.1  Host  Sites 

The  function  of  the  host  site  is  to  generate  new  messages  and  destroy  messages 
sent  from  other  host  nodes.  Each  host  site  consists  of: 

•  A  Host  processor 

•  A  Network  Interface  Processor  (NIP) 

•  A  variable  number  of  internodel  transmission  devices 

•  2  Channels 

•  1  Buffer 

The  host  sites  in  tne  Detail  Models  differs  from  host  sites  in  HLM  Models 
(Section  3)  by  allowing  host  to  perform  both  host  functions  and  switching 
functions.  Thus,  one  model  (Model  1  -  Host  Sites)  would  have  been  sufficient 
to  simulate  the  different  complexity  levels,  however  two  models  -  Host  and 
Switch  -  were  retained.  The  Switching  Model  is  available  for  simulating  nodes 
performing  switching  functions  exclusively. 
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Figure  6. 2. 3. 1-1  graphically  portrays  the  Host  Site  architecture. 


Table  5.2.3. 1-1  provides  a  summary  of  the  System  Description  for  the  Host 
Sites. 


Taole  5. 2. 3. 1-1  System  Description  for  Host  Site 


DEVICE  NAME 

ECSS  DEVICE  TYPE 

PERFORMANCE 

SPECIFICATIONS 

DOIA.CPU 

(Processor) 

EXECUTIONS  AND 

JOB  STORE  DEVICE 

500,000  INSTRUCTIONS 
/SEC 

DOIA.NIP 

(Network  Interface 
Processor) 

NETWORK  INPUT 

PROCESSOR  EXECUTES 

AND  JOB  STORE  DEVICES 

500,000  INSTRUCTIONS 
/SEC 

TOlA.MOl  (internodal 
Transmission  Device) 

TRANSMISSION  DEVICE 

20,000  SYTES/SEC 

DOIB.  CHANNELS 
(Channel ) 

TRANSMISSION  DEVICE 

20,000  BYTES/SEC 

DOIO.BUF  (Buffer) 

STORAGE  DEVICE 

10,000  BYTES 

DOIC. TERMINAL 
(Terminal ) 

I/O  DEVICE 

9600  BYTES/SEC 

POIA.T.PATH 
(Internodal  Path) 

PATH 

CONNECT  DOIB.  CHANNELS 

TO  DOIC  TERMINALS 
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igure  5. 2. 3. 1-1  Host  Site  Configuration 


3 


The  funccion  of  the  switching  node  is  to  accept  ana  forward  messages  along  tne 
network.  Each  switching  node  consists  of: 

•  A  Processor 

•  A  variaole  number  of  Internodal  Transmission  devices 

•  A  Buffer 

The  Processor  and  Buffer  declarations  are  provided  in  the  DSS  Switching 
Model.  The  specifications  for  the  Internodal  Transmission  devices  are  defined 
in  tne  TP. FILE.  Figure  5. 2. 3. 2-1  graphically  displays  this  configuration. 
Table  5. 2. 3. 2-1  provides  a  summary  for  the  System  Description  Section  for  the 
switching  node. 


Figure  5. 2. 3. 2-1  Switching  Node  Configuration  (Oedicateo  Option) 
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Table  5. 2. 3. 2-1  System  Description  for  Switching  Node 


DEVICE 

NAf-IE 

DEVICE 

TYPE 

ECSS 

performance 

SPECIFICATIONS 

032A.CPU 

EXECUTION  AND 

500.000  INSTRUCTIONS/SEC 

( Processor ) 

JOB  STORE  UEVICE 

T02A.M01  (Internodal 

Transmission  Device) 

TRANSMISSION 

DEVICES 

30,000  3YTES/SEC 

0028. BUF 

( Buffer) 

STORAGE 

DEVICE 

10,000  BYTES 

FOIA.NOI .N02 

(Internodal  Path) 

PATH 

CONNECTS  TOIA.MOl 

TO  T02A.M02 
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5.2.4  FUNCTIONAL  LOGIC  FLOW 

The  Communication  Protocol  Model  simulates  a  Switched  Virtual  Circuit  (SVCj 
Packet  Service  Network  that  includes  Datagrams.  Host  sites  contain  a  Host 
Processor  which  generates  messages  and  forwards  them  to  the  host  site  Network 
Interface  Processor  (NIP).  If  the  message  is  a  Datagram,  then  the  NIP  will 
interject  the  message  into  tne  network  ana  it  will  travel  to  its  destination 
in  a  manner  similar  to  the  messages  in  High  Level  Models  1  and  2. 

If  tne  message  requires  a  SVC,  the  virtual  circuit  will  be  allocated  as  a 
connecting  log  of  nodes  from  originator  to  target.  For  example, 


Figure  5. 2. 4-1  CP  Topology  -  Level  C 


given  the  5  node  network  illustrated  in  Figure  5. 2. 4-1,  with  node  1  as  the 
originator  and  node  5  as  the  target,  two  possible  virtual  circuits  exist: 

0  VC  A  -  1  to  2  to  3  to  5 
0  VC  8  -  1  to  2  to  4  to  5 

Whichever  VC  is  taken  by  bcth  the  'Call  Request'  and  'Call  Accept'  messages, 
that  same  VC  will  be  used  for  all  data  packets  of  the  original  messages. 
Switching  sites  accept  and  forward  messages.  The  next  node  to  forward  a 
message  is  determined  by  the  allocated  VC.  Finally,  the  target  NIP  accepts 
the  packets,  reassembles  the  packets  into  the  original  message,  updates 
message  statistics,  passes  the  message  to  its  Host  Processor  and  sends  a  'call 
clear'  back  to  the  originator. 
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Figure  5. 2.4-2  is  a  High  Level  Func:ional  Fiow  of  tnis  process.  Table  5. 2. 4-1 
lists  the  message  types  while  Table  6. 2. 4-2  provides  a  detailed  functional 
flow  of  the  Communications  Protocol  Model.  The  message  types  4  through  9  are 
High  Level  Data  Link  Control  (HOLC^  message  types.  HDLC  is  one  of  the  most 
popular  "bit-oriented"  Data  Link  Control  (OLC)  protocols.  The  purpose  of  a 
OLC  Protocol  is  to  assure  the  bit  stream  received  is  an  error-free  replica  of 
the  bit  stream  transmitted  [GREE  30j. 


Table  5. 2. 4-1  Communication  Protocol  Message  Types 


MESSAGE 

TYPE 

DESCRIPTION 

1 

TERMINAL  TO  HOST 

2 

HOST  TO  NIP 

3 

RECEIVE  AT  NIP  -  CHECK  IF  VIRTUAL  CIRCUIT  REQUIRED 

*4 

CALL  REQUEST 

*5 

CALL  ACCEPTED 

*6 

DATA  PACKETS 

*7 

ACKNOWLEDGEMENT  BETWEEN  NODES 

*8 

PACKETS  REASSEMBLED  INTO  ORIGINAL  MESSAGE, 

PASSED  TO  HOST  APPLICATION  LEVEL 

*9 

CLEAR  REQUEST 

10 

ORIGINAL  MESSAGE  TO  BE  RETRANSMITTED 

*  HOLC  MESSAGE  TYPES 
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Switching  node  accepts 
and  forwards  message 
using  Virtual  Circuit 


MESSAGE  TYPE  5 


Target  node  sends 
cal  1  accept  back 
to  originating  Host 


)  may  require  several 

'  MESSAGE  TRANSFERS 
(  DEPENDING  ON  NETWORK 
;  TOPOLOGY 


Figure  5. 2.4-2  High  Level  Functional  Flow  of  Communication  Protocol  Model 


Switching  node  accepts 
and  forwards  message 
using  Virtual  Circuit 


Originating  node  sends 
Data  in  packet  form  to 
target  Host 


Switching  node  accepts 
and  forwards  message 
using  Virtual  Circuit 


Target  node  reassembles 
message  and  sends  cal  1 
clear  back  to  originator 


Switching  node  accepts 
message  and  forwards 
using  Virtual  Circuit. 


Originating  node  '•el eases 
Virtual  Circuit 


Figure  5. 2. ‘1-2  High  Level  Functional  Flow  of  Communication  Protocol  Model 

(CONTINUED) 


Functional  Flow  Coninunlcatlon  Protocol  Model 


Table  UetaileU  Functional  Flow  for  Communication  Protocol  Mode 


Aa<NOWlEDC£  PA«tT  -  irpE  7  PC  (PI 

HEAiSEMBlE  PAtKEtS  INIO  (TKIGINAI  AK  <J) 

MESbA(*  PA  (J) 
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Table  5.i'.4-2  Detailed  FimLlional  Flow  for  Corntnutiication  Protocol  Minlcl 

( Continued) 
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Two  major  external  processes  provide  the  control  functions  (e.g.,  message 
generation  and  starting  computer  Jobsl  for  the  communication  protocol  model. 
They  are: 

•  ARR  process  (message  generation) 

•  CP  Process  (communication  process  -  controlling  computer  jobs) 

A  brief  description  of  each  process  is  provided: 

'^ssace  Generation  -  External  Process  ..ARR 

The  ..ARR  process  provides  the  vehicle  for  generating  every  message  introduced 
into  the  network.  Tnis  process  simply  cycles  according  to  the  interarrival 
rate  (■’^IT)  established  in  tne  MESS  file  or  defaulted  in  the  EXEC  file. 
Messages  are  created  each  time  the  process  cycles.  The  number  of  instances  of 
..ARR  in  the  external  Process  Reports  indicates  the  number  of  different 
message  types  generated  during  the  simulation  run. 

Communication  Process  -  External  Process  CP 

The  primary  function  of  the  communication  process  is  to  control  the 
communication  between  nodes.  A  communication  process  may  start  jobs  on  a 
processing  unit  which  simulates  the  activity  of  transferring,  switching  and 
receiving  messages.  Statistics  on  these  external  processes  are  displayed  on 
the  External  Process  Report.  The  number  of  instances  for  the  CP  processes 
should  oe  one.  These  processes  are  started  only  once  and  continue  to  operate 
for  the  full  duration  of  the  simulation. 

The  communication  process  activates  and  controls  these  jobs: 

t  J08  SM  f  JOB  AK 

•  JOB  RM  •  JOB  PA 

•  JOB  HT  •  JOB  PC 

•  JOB  TH 

•  JOB  HN 

•  JOB  NH 
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A  descripcion  of  these  joos  is  provided. 


JUB  SM  -  Message  Transferring 

JOB  SiM  sifTiulates  the  activity  of  transfenng  a  -nessage  from  a  current  site  to 
the  next  node.  It  accomplishes  this  task  by  filing  the  pointer  to  the  message 
(MSG)  data  in  the  switching  nodes  message  file  (..MGflJE).  The  JOB  concludes 
by  signaling  the  switching  node.  Tnis  notifies  the  communication  process  tnat 
it  has  a  message  waiting  for  it.  The  total  number  of  instances  for  a  unique 
JOB  SM  can  be  interpreted  as  the  total  number  of  messages  transmitted  from  one 
s'te  tc  anctner. 

JOB  RM  -  Retransmit  Message 

Job  KM  simulates  the  retransmission  of  a  message  if  an  acknowledgement  has  not 
been  received  within  a  user  specified  time.  The  number  of  instances  of  JOB  RH 
indicates  the  number  of  packets  sent  from  a  particular  node  which  were 
rejected  by  an  adjacent  node. 

JOB  AK  -  Acknowledgement 

Job  Ak  is  responsible  for  sending  acknowledgements  for  accepted  packets.  This 
job  is  only  operational  when  a  ’M"  is  indicated  for  "ACK"  in  the  EXEC  file. 
The  number  of  instances  of  JOB  AK  indicates  the  number  of  packets  accepted  by 
a  particular  node. 

JUB  PA  -  Packet  Retransmit 

Job  PA  simulates  the  reassembly  of  a  message  at  the  NIP.  The  number  of 
instances  of  Job  PA  indicates  the  total  number  of  completely  reassembled 
messages  at  a  host  node. 

JOB  PC  -  Post  Communication 

Job  PC  is  the  timing  mechanism  that  schedules  the  retransmit  command  for  all 
unacknowledged  packets.  The  user  specifies  the  frequency  with  wnich  this  joo 
is  performed  by  selecting  the  maximum  response  time  tolerable  for  all 
acknowledgements  at  the  host  (TMH)  and  switching  nodes  (TMC).  The  number  of 
instances  of  this  job  indicates  how  many  times  a  particular  node  assessed  the 
status  of  its  outgoing  packets. 
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JOB  TH-  Terminal  to  Host  Transmission 

This  joD  simulates  the  transferring  of  a  message  from  a  host  site's  terminal 
to  the  host  processor.  Tasks  accomplished  by  this  job  are: 


t  Sending  appropriate  bytes  from  a  randomly  selected  terminal  via  a 
randomly  selected  channel, 

•  Message  type  is  changed  from  a  new  message  (Type  1)  to  'received  at 
Host ' ,  ( Type  2) , 

t  Message  is  then  filed  in  current  node's  message  file, 

•  CP  is  signaled. 

Number  of  unique  occurances  of  this  job  can  be  interpreted  as  total  messages 
received  at  that  Host  from  its  users. 

JOB  HN-  Host  to  NIP  Transfer 

This  job  ihcreases  simulation  time  to  model  the  overhead  incurred  by  the  host 
CPU  when  relaying  a  message  to  its  Network  Interface  Processor  (NIP).  JOB  HN 
accomplishes  this  by  changing  message  type  to  'received  at  NIP'  (Type  3), 
filing  the  message  in  its  message  file  and  signaling  CP.  Total  number  of 

instances  for  this  job  for  any  given  node,  represents  total  number  of  messages 
entered  into  network. 

JOB  NH-  NIP  to  Host  Transfer 

This  job  incurs  simulation  time  to  represent  overhead  when  messages  flow  from 
a  Host  site  NIP  to  its  Host  CPU.  Total  number  of  instances  for  that  node 

represent  number  of  messages  received  by  that  node  from  the  network. 

JOB  HT  -  Host  to  Terminal  Transfer 

This  joD  simulates  the  transferring  of  a  message  from  a  Host  CPU  to  its 

terminals.  It  accomplishes  this  by  sending  appropriate  bytes  via  a  randomly 
selected  channel  to  a  randomly  selected  terminal.  Total  number  of  instances 

for  this  job  for  any  given  node  represents  communication  activity  between  CPU 
and  its  terminals.  Refer  to  OSS  User's  Manual  for  more  information  relating 
to  Job/External  Process  reports. 
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5.2.6  SIMULATION  OUTPUT 

Tne  DSS  Simulator  produces  two  output  reports: 

t  Message  Statistics 

•  ECSS  Standard  Reports 

(See  Appendix  U  for  examples  j 

For  a  description  of  eacn  report  contained  in  tnis  section  refer  to  the  User's 
Manual.  For  a  complete  sample  of  these  reports  refer  to  Appendix  U 

5.3  R£-lA8IuITY/AVAlLAblLlTY  MODEL 

The  Pel i doi 1 i ty/Avai 1 abi 1 i ty  Model  extends  the  Oommuni cation  Protocol  Model  oy 
accounting  for  nodal  failures  and  network  transmission  errors.  Two  new 
mechanisms  -  rejections  and  adaptive  routing  are  introduced  in  this  model. 

5.3.1  NETWORK  RELIABILITY 

Reliability  is  a  major  concern  in  communications  oriented  systems. 
Communication  lines  can  fail  to  give  adequate  service  in  one  of  the  following 
ways: 

•  Line  errors  -  Some  data  transmitted  over  the  line  are  garbled  due  to 
bits  being  added  or  lost. 

t  Line  Outages  -  The  connecting  line  can  become  unavailable  causing 
transmissions  to  be  blocked  if  an  alternative  line  cannot  be  provided. 

•  Engaged  or  Busy  Signals  -  A  target  node  may  be  at  maximum  capacity  in 
respect  to  network  inputs  or  outputs  and  thus  unavailable. 

•  Pi  sconnections  -  A  node  on  the  network  can  'crash'  and  disconnect 
Itself  from  the  network  until  it  recovers.  If  the  node  is  a  host, 
internal  processing  may  continue  while  isolated  from  the  network. 

Certain  steps  can  be  taken  to  improve  reliability.  They  include: 

•  Automatic  Retry  -  When  the  line  fails  to  send  the  data  and  no 
acknowledgement  is  received,  the  sender  will  retransmit  the  message. 
This  process  is  of  most  value  when  outages  are  of  short  durations. 
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•  Alternate  Patns  -  Tne  network  communication  lines  can  be  duplicated  in 
part,  for  reliaoility.  Two  or  more  communication  lines  may  share  the 
load  from  a  gwen  location  to  another,  when  one  line  fails,  service  is 
available  on  the  alternate  line.  In  a  packet  -  switching  network, 
packets  can  traverse  the  network,  by  passing  parts  of  the  network  that 
have  failed.  Packet  switching  thus  forms  the  basis  of  an  adaptive 
networK  that  automatically  adjusts  tne  route  which  the  packet 
traverses,  to  bypass  failed  lines  or  failed  nodes. 

•  Buffering  -  As  a  'last  resort*  tactic,  messages  blocked  at  a  sending 
node  can  be  buffered  until  the  required  circuit  becomes  available. 

The  Rel i abi 1 i ty/Avai I abi 1 1 ty  Model  uses  all  the  above  methods  to  compensate 
for  line  and  nodal  failures. 

5.3.2  LAYERED  APPROACH  TO  BUILDING  RELIABILITY/AVAILABILITY  MODEL 

The  Communication  Protocol  Model  described  in  4.2  formed  the  foundation  for 
the  new  Reliability/Availability  Model.  The  communication  mechanisms 
developed  in  the  Communication  Protocol  Model  were  only  slightly  adapted  to 
accomodate  the  network  support  system  required  by  the 
Reliability/Availability  Model.  New  jobs  were  added  with  minimal  impact  to 
existing  jobs. 

Upward  compatabi 1 i ty  of  the  CP  model  was  retained,  since  the  CP  model  could  be 
replicated  by  the  R/A  model  if  the  user  specifies  no  transmission  error  and  no 
nodal  crashes. 

5.3.3  MODEL  ARCHITECTURE 

The  R/A  model  consists  of  two  model  types; 

•  A  model  to  describe  the  behavior  of  tne  host  sites  and 

•  A  model  to  describe  the  behavior  of  switching  nodes. 
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5. 3. 3.1  Host  Sites 

Tne  fjnction  of  the  host  site  is  to  generate  new  messages  and  cestroy  messages 
sent  from  other  host  nodes.  Each  host  site  consists  of: 

•  A  Host  processor 

•  A  Network  Interface  Processor  (NIP) 

•  A  variable  number  of  internooal  transmission  devices 

•  2  Channels 

•  1  Buffer 

Tne  nost  sites  in  the  Detail  Models  differs  from  host  sites  in  HLM  Models 
(Section  4)  by  allowing  host  to  perform  both  nost  functions  and  switching 
functions.  Thus,  one  model  tModel  1  -  Host  Sites)  would  have  been  sufficient 
to  simulate  the  different  complexity  levels;  however  two  models  -  Host  and 
Switch  -  were  retained.  The  Switching  Model  is  available  for  simulating  nodes 
performing  switching  functions  exclusively. 

'■tjre  5. 3. 3. 1-1  graphically  portrays  tne  Host  Site  architecture. 

Table  5. 3. 3. 1-1  provides  a  summary  of  the  System  Description  for  the  Host 
Sites. 
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TaOle  5.3.3. 1-1  Host  Site  Conf iguraticn 


DEVICE  NAME 

ECSS  DEVICE  TYPE 

performance 

SPECIFICATIONS 

DOIA.CPU 

(Processor) 

EXECUTIONS  ANDS 

JOB  STORE  DEVICE 

500,000  INSTRUCTIONS 
/SEC 

DOIA.NIP 

(Network  Interface 
Processor) 

NETWORK  INPUT 

PROCESSOR  EXECUTES 

AND  JOB  STORE  DEVICES 

500,000  INSTRUCTIONS 
/SEC 

TOlA.MOl  (Internodal 
Transmission  Device) 

TRANSMISSION  DEVICE 

20,000  BYTES/SEC 

DOIB.  CHANNELS 
(Channel ) 

TRANSMISSION  DEVICE 

20,000  BYTES/SEC 

001D.8UF  (Buffer) 

STORAGE  DEVICE 

10,000  BYTES 

OOlC. TERMINAL 
( Termi nal ) 

I/O  DEVICE 

9600  BYTES/SEC 

POIA.T.PATH 
(Internodal  Path) 

PATH 

CONNECT  001 B.  CHANNELS 

TO  DO  1C  TERMINALS 

Tne  function  of  the  switcning  node  is  to  accept  and  forward  messages  along  the 
network.  Each  switching  node  consists  of; 


•  A  Processor 

•  A  variable  number  of  Internooal  Transmission  devices 

•  A  Buffer 


The  Processor  and  Buffer  declarations  are  provided  in  the  DSS  Switching 
Model.  The  specifications  for  the  Internodal  Transmission  devices  are  defined 
in  the  TP. FILE.  Figure  5. 3. 3. 2-1  graphically  displays  the  switching  node 
configuration.  Table  5. 3. 3.2-1  provides  a  summary  for  the  System  Description 
Section  for  the  switching  node. 
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Figure  5. 3. 3. 2-1  Switching  Node  Configuration  (Dedicated  Option) 
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TaD]e  5. 3. 3. 2-1  System  Description  for  Switching  Node  | 


- 

DEVICE 

NAME 

DEVICE 

TYPE 

ECSS 

PERFORMANCE 

SPECIFICATIONS 

002A.CPU 

EXECUTION  AND 

500,000  INSTRUCTIONS/SEC 

1  (Processor) 

1 

JOB  STORE  DEVICE 

T02A.M01  finternodal 

Transmi ssion  Device) 

TRANSMISSION 

DEVICES 

30,000  BYTES/SEC 

D02B.8UF 

(Buffer) 

STORAGE 

DEVICE 

10,000  BYTES 

POIA.NOI .N02 

Internodal  Path) 

PATH 

CONNECTS  T01A.M01 

TO  T02A.M02 
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5.3.4  FUNCTIONAL  LOGIC  FLOW 

T/vo  rriajof  external  processes  provide  the  control  functions  (e.g.,  message 
generation  and  starting  computer  jobs)  for  the  R/A  model.  They  are: 

•  ..ARR  process  (message  generation^ 

•  CR  Process  (communication  process  -  controlling  computer  jobs) 

A  brief  description  of  each  process  is  provided: 

Message  Generation  -  External  Process  ..ARR 

The  ..ARR  process  provides  the  vehicle  for  generating  every  message  introduced 
into  the  network.  This  process  simply  cycles  according  to  the  interarrival 
rate  (MIT)  estaolished  in  the  MESS  file  or  defaulted  in  the  EXEC  file. 
Messages  are  created  each  time  the  process  cycles.  The  number  of  instances  of 
..ARR  in  the  external  Process  Reports  indicates  the  number  of  different 
message  types  generated  during  the  simulation  run. 

Communication  Process  -  External  Process  CP 

The  primary  function  of  the  communication  process  is  to  control  the 
communication  between  nodes.  A  cornnuniation  process  fnay  start  jobs  on  a 
processing  unit  which  simulates  the  activity  of  transferring,  switching  and 
receiving  messages.  Statistics  on  these  external  processes  are  displayed  on 
the  External  Process  Report.  The  number  of  instances  for  the  CP  processes 
should  be  one.  These  processes  are  started  only  once  and  continue  to  operate 
for  the  full  duration  of  the  simulation. 

Tne  cortimunication  process  activates  and  controls  these  jobs: 


JOB 

SM 

t 

JOB 

AK 

JOB 

RM 

• 

JOB 

PA 

JOB 

HT 

• 

JOB 

PC 

JOB 

TH 

• 

CD 

O 

RC 

JOB 

HN 

• 

JOB 

RD 

JOB 

NH 
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■A  description  of  these  jobs  is  provided. 

JOB  S.'-l  -  Message  Transferring 

JOB  SM  simulates  the  activity  of  transfering  a  message  from  a  current  site  to 
the  next  node.  It  accomplishes  this  task  by  filing  the  pointer  to  the  message 
(MSG/  data  in  the  switching  nodes  nessage  file  (..MGFILE).  The  JOB  concludes 
by  signaling  the  switching  node,  "his  notifies  the  communication  process  that 
it  has  a  message  waiting  for  it.  The  total  number  of  instances  for  a  unique 
JOB  SM  can  be  interpreted  as  the  total  number  of  messages  transmitted  from  one 

JOB  RM  -  Retransmit  Message 

JOB  KM  simulates  the  retransmission  of  a  message  if  an  acknowledgement  has  not 
been  received  within  a  user  specified  time.  The  number  of  instances  of  Job  RM 
indicates  the  number  of  packets  sent  from  a  particular  node  which  were 
rejected  by  an  adjacent  node. 

JOB  AK  -  Acknowledgement 

JOB  mK  is  responsible  for  sending  acknowledgements  for  accepted  packets.  This 
job  is  only  operational  when  a  "I"  is  indicated  for  "ACK"  in  the  EXEC  file. 
The  number  of  instances  of  JOB  AK  indicates  the  number  of  packets  accepted  by 
a  particula-  node. 

JOB  PA  -  Packet  Assembly 

JOB  PA  simulates  the  reassembly  of  a  message  at  the  NIP.  Tne  number  of 
instances  of  JOB  PA  indicates  the  total  number  of  completely  reassembled 
messages  at  a  host  node. 

JOB  PC  -  Post  Communication 

JOB  PC  is  the  timing  mechanism  that  schedules  the  retransmit  command  for  all 
unacknowledged  packets.  The  user  specifies  the  frequency  in  which  this  job  is 
performed  by  selecting  the  maximum  response  time  tolerable  for  all 
acknowledgements  at  the  host  (TMH)  and  switching  nodes  (TMC).  The  number  of 
instances  of  this  job  indicates  how  many  times  a  particular  node  assessed  the 
status  of  its  outgoing  packets. 


003  J1 


5-35 


JOB  TH-  Terminal  to  Host  Transmission 

This  job  simulates  the  transfering  of  a  message  from  a  host  site's  terminal  to 
the  host  processor.  Tasks  accomplished  by  this  job  are: 


•  Senaing  appropriate  bytes  from  a  randomly  selected  terminal  via  a 
randomly  selected  channel, 

•  Message  type  is  changed  from  a  new  message  (Type  Ij  to  ‘received  at 
Host',  (Type  2), 

•  Message  is  then  filed  in  current  node's  message  file, 

•  CP  is  signaled. 

Number  of  unique  occurances  of  this  joo  can  be  interpreted  as  total  messages 
received  at  that  host  from  its  users. 

JOB  HN-  Host  to  NIP  Transfer 

This  job  increases  simulation  time  to  model  the  overhead  incurred  by  the  HOST 
CPU  when  relaying  a  message  to  its  Network  Interface  Processor  (NIP).  JOB  HN 
accomplishes  this  by  changing  message  type  to  received  at  NIP'  (Type  3), 
filing  the  message  in  its  message  file  and  signaling  CP.  Total  number  of 

instances  for  this  job  for  any  given  node  represents  total  number  of  messages 
entered  into  network. 

JOB  NH-  NIP  to  Host  Transfer 

This  job  incurrs  simulation  time  to  represent  overhead  when  messages  flow  from 
a  Host  site  NIP  to  its  Host  CPU.  Total  number  of  instances  for  that  node 

represent  number  of  messages  received  by  that  node  from  the  network. 

JOB  HT  -  Host  to  Terminal  Transfer 

This  job  simulates  the  transferring  of  a  message  from  a  Host  CPU  to  its 

terminals.  It  accomplishes  this  by  sending  appropriate  bytes  via  a  randomly 
selected  channel  to  a  randomly  selected  terminal.  Total  number  of  instances 

for  this  job  for  any  given  node  represents  communication  activity  between  CPU 
and  its  terminals. 
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Tois  job  si'nulates  tbe  selection  or  3  new  virtual  circuit  wnen  the  next  nooe 
in  the  current  virtual  circuit  is  out  of  buffer  space.  Total  number  of 
instances  represents  network  rerouting  oue  to  traffic  overload. 


JOB  RC  -  Reroute  because  of  Nodal  Failure 

Tnis  job  simulates  the  selection  of  a  new  virtual  circuit  when  the  next  node 
in  tne  Current  virtual  circuit  is  iisconnected  from  tne  network.  Total  number 
of  iristances  represents  network  rerouting  due  to  nodal  failures. 

^e..  external  processes  were  aoced  to  the  K/A  model  to  smulace  tne  fai  j^e 
of  ncdal  sites.  They  are: 

ExTEkNmL  process  -  RECQV 

Controls  the  time  interval  a  node  is  unavailable  to  the  network.  When  the 

External  Process  RECOV  is  signalled  after  the  duration  of  tne  crash,  the 

node's  status  is  togglea  to  1  (up). 

external  process  -  CRASH 

Controls  the  time  interval  between  failures  for  a  network  node.  After  a  time 

inte’'val  has  elapsed,  the  External  Process  CRASH  is  signaled  and  the  node's 

status  is  toggled  to  0  (Down). 


Figure  5. 3.4-1  External  Process  CRASH  and  RECOV  Relationship 

Figure  5. 3. 4-1  shows  the  relationship  between  R/A  model's  external  process 
CRASH  ana  external  process  RECOV  (uee  5. 3. 4. 2  Nodal  Failures). 
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Fron  a  functional  perspective,  tnree  new  .necnanisn  were  added  to  the  C/P  model 
to  implement  the  R/A  model.  The  three  mechanisms  were: 

1  Transmission  Errors 

2  Nodal  Failures 

3  Adaptive  Routing 

The  following  sections  will  describe  each  mechanism  in  detail. 

5. 3. 4.1  Transmission  Errors 

'ransmission  errors  are  modeled  in  the  Rel i aoi 1 i ty/Avai 1 abi 1 i ty  Model  by 
inputting  a  user  specified  reject  factor.  The  user  can  specify  a  rejeci 
factor  of  less  than  1.0  (e.g.,  .20  for  20%);  its  complement  would  of  course, 
be  the  site's  reliability  factor.  If  no  reject  factor  (REJ)  is  specified  in 
the  EXEC  file,  the  model  will  default  REJ  to  0. 

The  functional  logic  flow  for  rejects  is  displayed  in  Figure  5. 3. 4. 1-1.  If  a 
message  arrives  at  a  node  other  then  the  originator,  and  it  is  not  an 
acknowledgement  (type  =  7)  and  not  an  intranodal  message  (type  =  1,  2,  3  or 
8),  then  the  message  is  tested  for  rejection.  The  rejection  test  involves  a 
uniform  random  number  in  the  open  interval  (0,1)  being  compared  to  the  reject 
factor.  When  a  message  is  rejected  by  a  receiving  node,  no  acknowledgement 
will  be  sent.  Once  the  maximum  time  out  (TMO)  has  been  exceeded,  the  sending 
node  will  retransmit  the  message  that  was  rejected. 

5. 3.4.2  Nodal  Failures 

One  of  the  major  differences  between  the  Communication  Protocol  Model  and  the 
Rel i aoi I i ty/Avai labi 1 ity  Model  is  the  simulation  of  a  nodal  failure.  A 
network  node  becomes  unavailable  by  a  line  outage,  mechanical  failure  or 
because  it  has  temporarily  used  all  of  its  buffer  space.  Two  new  attributes 
for  eacn  node  were  added: 

STATUS  -  0  -  down 
1  -  up 

VC.NUM  -  Number  of  virtual  circuits  already  allocated 
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NEW  MESSAGE  TYPE  NOT 
INTRA  NODAL  MESSAGE 
OR  AN  ACKNOWLEDGEMENT 


t 


Figure  5. 3.4.1 
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The  following  user  parameters  were  added  to  the  EXEC  file: 


MTC  -  mean  time  between  crashes 
DMS  -  distribution  for  MTC 
MOT  -  mean  down  time 
DM0  -  distribution  for  MOT 

Distribution  options  are: 

1  -  ^o  Change  from  EXEC  file 

specified  value 

2  -  Uniform  distribution 

3  -  Exponential  distribution 

For  each  node  an  interval  (MTC)  between  crashes  will  be  computed;  when  that 
simulation  time  has  elapsed,  the  status  variable  will  be  set  to  represent  a 
downed  site.  Another  computation  using  MOT  will  result  in  the  interval 
representing  the  duration  of  the  crash.  After  the  down  time  has  elapsed,  the 
status  value  will  be  toggled  to  represent  up.  As  each  virtual  circuit  is 
allocatec,  the  number  of  virtual  circuits  for  any  node  on  the  virtual  circuit 
IS  ircrementea.  As  a  virtual  circuit  is  released,  each  node  on  that  virtual 
circuit  has  its  variable  VC.NUM  decremented. 

5. 3.4. 3  Adaptive  Routing 

In  the  Rel  i  abi  1  i  ty/Avai  1  abl  i  ty  Model  a  message  has  a  choice  of  paths  that  can 

be  travelled  to  a  target  node.  The  user  specifies  the  possible  multiple  paths 

that  exist  via  the  route  file.  When  a  virtual  circuit  is  to  be  chosen,  the  VC 

request  routine  will  build  a  virtual  circuit  log  one  node  at  a  time.  Each 

node  added  to  a  virtual  circuit  will  be  chosen  from  alternatives  using  the 
following  two  step  criteria: 
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1)  Eliminate  from  possible  next  nodes  any  nodes  dov/n  and  any  nodes 
already  at  maximum  virtual  circuits. 

2)  Select  the  node  *vith  the  least  number  of  virtual  circuits  allocated. 

The  second  step  minimizes  network  congestion,  a  similar  approach  is  used  in 
routine  VC. NODE  when  a  node  in  the  virtual  circuit  fails  after  the  message  nas 
left  the  originating  node.  Thus,  the  new  virtual  circuit  retains  nodes 
already  traversed  and  appends  nodes  that  are  up  and  least  busy.  If  no  valid 
alternate  virtual  circuit  is  possible,  the  message  will  oe  buffered  until  a 
virtual  circuit  becomes  available.  The  function  flow  chart  for  this  adaptive 
routing  is  presented  in  Figure  5. 3. 4. 3-1 

5.3.5  SIMULATION  OUTPUT 

The  OSS  Simulator  produces  two  output  reports: 

•  Message  Statistics 

•  ECSS  Standard  Reports 

(See  Appendix  E  for  examples  ) 

For  a  description  of  each  report  contained  in  this  section  refer  to  the  User's 
Manual.  For  a  complete  sample  of  these  reports  refer  to  Appendix  E. 

5.4  DISTRIBUTED  DATABASE  MODEL 

The  DB  model  provides  a  tool  for  the  system  designer  to  model  and  study  a 
proposed  Distributed  Database  Management  System  (DDMS)  during  its  planning 
stages.  Availability  of  such  a  tool  is  important  because  performance 
characteristics  of  a  DDBM  System  is  dependent  on  many  factors.  Simulation 
models  can  help  in  the  analyses  that  are  necessary  to  design  a  cost-effective 
system  that  meets  certain  performance  requirements.  The  DB  Model  includes 
these  components: 

•  Transaction  Updates/Modifications 

•  Transaction  Retrievals 
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•  Number  of  Lockups 

•  Concurrency  Control 

•  Fi le  A1 location 

•  Transaction  Rates 

•  Transmission  Overhead 

•  Processor  Uti 1 ization 

•  Buffer  Utilization 

•  Average  Queue  Lengths  at  File  Servers 

•  Delays  due  to  Blocking/Synchronization 

•  Transaction  Throughput 

•  Transaction  Response  Time 

Tne  functional  characteristics  of  tne  model  are  such  that  tne  user  may  vary  a 
wide  range  of  DOBM  System  parameters  and  study  the  effects  in  terms  of  the 
resource  utilization  (channels,  processors,  buffers,  transmission  paths)  and 
the  net  user  effect  (throughputs,  response  times). 

The  OB  model  will  oe  explained  by  first  describing  the  Distributed  Database 
Management  System  Architecture  used  as  a  reference  to  build  the  three 
submodels  that  compose  the  08  mode).  Each  submodel  will  then  be  describeo  in 
detail.  Finally,  the  DB  model  implementation  using  DSS  will  be  covered. 

5.4.1  DISTRIBUTED  DATABASE  MANAGEMENT  SYSTEM  ARCHITECTURE 

A  Distributed  Database  Management  System  (DOBMS)  may  be  viewed  as  a  collection 
of  host  sites  connected  by  a  communication  sub-network.  Each  site  of  a  DDBMS 
contains  one  or  both  of  the  following  software  modules: 

•  A  Transaction  Manager  (TM)  that  supervises  transactions  between  users 
and  the  DOBMS. 

•  A  Data  Manager  (DM)  that  manages  the  stored  Database. 

Thus,  a  DDBMS  contains  four  elements:  transactions,  TMs,  DMs  anc  data  (Figure 
5. 4. 1-1).  A  user's  transactions  communicate  with  TMs  which  communicate  with 
DMs  and  DMs  manage  the  data.  TMs  cannot  communicate  with  other  TMs  nor  can 
DMs  communicate  with  other  DMs.  [BERN  81j. 


Tnis  model  of  d  006MS  assumes  perfectly  reliable  communication  links  between 
nodes.  In  order  to  make  the  model  more  realistic  the  OB  Model  used  the 
services  provided  by  the  Rel iabilUy/Avai labi 1 ity  (R/A)  and  the  Communication 
Protocol  (CP)  Models.  In  this  section,  however,  we  will  be  concerned 
primarily  with  the  model  elements  that  are  specific  to  a  OOBMS.  Models  of 
nodal  and  transmission  failures  as  well  as  the  X.25  interface  model  are 
descrioed  in  preceeding  sections  (See  5.1  and  5.2). 

The  OB  model  consists  of  three  sub-models. 

The  three  sub  models  are: 

•  Database  Topology  submodel  (OT)  which  simulates  distribution  of  data 
across  a  computer  network  (See  4. 4. 1.1). 

•  Transaction  Manager  submodel  (TM)  which  simulates  the  supervision  of 
transactions  by  the  TM  module  of  a  OOBMS  (See  4. 4. 1.2). 

•  Data  Manager  submodel  (DM)  which  simulates  the  actual  management  of 
stored  data  by  a  QM  (See  4. 4. 1.3). 

As  stated  before,  the  Communication  Protocol  Mechanisms  were  utilized  to 
transport  data  and  transactions  across  a  packet-switched  network.  The 
Reliability/Availability  Model's  mechanisms  of  transmission  errors  and  nodal 
failures  were  utilized  to  simulate  the  real  world  constraints  imposed  on  any 
Distributed  Database  System. 

Each  of  the  three  submodels  will  now  be  described  in  detail  in  the  following 
sections. 


5. 4. 1.1  Database  Topology  (DT)  SubModel 

Tne  Database  submodel  contains  three  major  elements 

1)  File  allocation  -  Which  allows  the  user  to  map  logical  files  to 

network  nodes. 

2)  Data  granularity  -  Which  provides  the  user  with  tne  flexability  to 
define  the  level  of  abstraction.  Data  can  be  modeled  as  an  entire 
database,  files,  records  or  even  fields  within  a  record. 
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3)  Physical  and  Logical  Oatabase  units  -  Both  logical  and  physical 
database  units  can  be  defined  by  the  modeller.  A  logical  database 
unit  can  be  declared  as  residing  at  only  one  node  (centralized)  or 
replicated  at  several  nodes  (decentralized).  A  physical  database  unit 
can  be  declared  as  physically  locatea  on  a  particular  disk  within  a 
nodal  site. 

5. 4. 1.2  Transaction  Manager  (TM)  SubModel 

A  transaction  is  defined  as  a  sequence  of  reads  and  writes  (R/W)  issued  by  a 
database  user.  The  idea  of  a  message  used  in  the  previous  mode's 
(Communication  Protocol,  Pel i abi 1 i ty/Avai 1 abi 1 i ty)  has  been  expanded  to 
incorporate  the  more  general  notion  of  a  transaction.  Just  as  parameters  were 
available  to  declare  the  dimensions  of  a  message,  the  following  parameters  are 
available  to  define  transactions: 

•  Mean  transaction  lengtn  -  the  average  number  of  R/W  operators. 

•  Read/Write  Ratio  -  allows  the  analyst  to  declare  the  proportion  of 

reads  to  writes.  In  a  distributed  database,  a  read  will  only  acce.s 

one  copy  of  a  file  with  preference  for  the  local  copy  (if  one  exists). 

A  write  to  any  particular  file  must  be  exploded  to  the  number 

necessary  to  update  all  file  copies  existing  in  a  distributed  database. 

•  Originating  node  -  this  is  the  node  from  which  transactions  are 

generated  and  can  be  specified  by  the  user. 

The  software  module  of  a  ODBMS  that  supervises  interactions  between 

transactions  and  the  DOBMS  is  called  a  Transaction  Manager  (TM).  In  the 
Distributed  Oatabase  Model  an  external  process  named  TM  is  used  to  model  the 
Transaction  Manager.  Figure  5. 4. 1.2-1  is  the  functional  flow  chart  for  the  TM 
external  Process.  When  a  message  (Type  1)  is  received  by  a  host  from  a 

terminal,  external  process  TM  is  started.  External  process  TM  will  perform 

the  following  functions: 
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Figure  5. 4. 1.2-1  Functional  Flow  Chart  Transaction  Manager 
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•  Generate  tne  appropriate  read  ana  write  operations  as  new  .nessages 
with  target  files. 

•  If  a  write  was  generated,  duplicates  will  pe  created  for  each  node 
that  contains  a  copy  of  that  target  file. 

•  A  database  directory  lookup  will  be  performed  using  the  declarations 
from  the  OT  File  to  obtain  the  nodal  location  and  disk  number  for  each 
file.  On  a  read  operation,  the  local  file  will  be  used  if  ohe  exists. 

•  Each  R/W  operation  is  assigned  a  global  timestamp  to  be  used  f  ir 
timestamp  ordering. 

•  Each  R/W  operation  message  is  filed  in  the  curreht  node's  message  file. 

•  The  TM  then  tracks  all  R/W  operations  created  and  upon  their  return, 

checks  for  ahy  rejects.  If  any  K/W  operatioh  was  rejected,  the  TM 

will  restart  the  transaction. 

«  Upon  receipt  of  all  R/W  operations  originally  dispatched,  the  TM  will 
start  JOB  HT  which  signals  the  originating  terminal  tnat  the 
transaction  was  completed  or  restarted. 

5. 4. 1.3  Database  Manager  (DM)  SubMpdel 

The  Database  Mahager  (DM)  is  the  DOBMS  software  module  that  manages  the  stored 
database.  TMs  issue  conmands  to  OMs  specifying  stored  database  units  to  be 

read  or  written.  In  a  distributed  database  environment,  DMs  may  receive 
commands  from  many  TMs  (See  Figure  5. 4. 1-1).  Because  DMs  may  receive 

operations  from  two  or  more  TMs  against  the  same  database  unit,  conflicts  may 
occur.  For  example,  if  two  different  TMs  issued  simultaneous  write  operatons 
against  the  same  database  item,  a  subsequent  read  operation  could  result  in  an 
inconsistency  at  different  sites  depending  on  the  sequence  of  the  write 
operations. 

Concurrency  control  is  the  activity  of  preventing  interference  among 

transactions  that  simul taheously  access  a  shared  database.  It  is  the 
concurrency  control  mechanism  that  must  resolve  the  conflict  between  different 
TM  operations  against  the  same  data  item.  The  concurrency  control  algoritnm 
implemented  in  the  DB  model  is  Timestamp  Ordering  (T/0). 
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Tne  tunctional  logic  flow  for  the  T/0  is  displayed  in  Figure  5. 4. 1.3-1. 

The  major  functions  that  a  T/0  scheduler  performs  are  listed  below. 

1)  TMs  assign  a  globally  unique  timestamp  for  each  transaction. 

2)  TMs  attach  the  transaction  timestamp  to  each  of  its  R/W  operations. 

3)  DMs  must  process  conflicting  operations  in  timestamp  order. 

4)  If  an  operation  arrives  'late'  with  a  timestamp  less  than  the 
timestamp  of  the  last  successful  operation  against  that  data  item;  the 
operation  is  rejected  by  DM.  This  rejection  occurs  before  the  actual 
stored  data  has  been  impacted  to  avoid  the  complexity  of  rollback. 

5)  The  TM  that  originated  the  operation  will  audit  each  returning 
operation.  If  any  operation  was  rejected  oy  a  DM,  the  TM  will  restart 
the  transaction  [BERN  81]. 

T/0  is  a  type  of  schedule  control.  Schedulers  can  delay  or  reject 
transactons.  In  a  distributed  environment  schedulers  can  be  centrally  located 
or  distriDuted  throughout  the  network.  In  the  DB  model  the  T/0  scheduler  was 
implemented  as  distributed  control  residing  at  each  host  site  and  performed  by 
DMs. 
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2A160/7A 

5. 4. 1.3-1  Functional  LOGIC  Flow  for  timestamp  Ordering  (T/0)  Scnedul 


5.4.2  LAYERED  APPROACH  TO  BUILDING  DATABASE  MODEL 

The  CP  and  R/A  models  formed  the  Duilding  blocks  of  the  D6  model.  Since  the 
DB  model's  domain  resided  at  the  application  level  (layer  7)  of  the  ISO 
Reference  Model  (see  5.1),  existing  R/A  and  CP  modules  corresponding  to  lower 
ISO  levels  were  utilized  without  change.  The  CP  model's  virtual  circuits 
provided  the  point-to-point  connection  for  transactions  to  access  remote  files 
while  the  R/A  model's  mechanisms  for  nodal  failures,  transmission  errors  and 
adaptive  routing  provide  a  more  realistic  setting  for  tne  Distributed  Database 
Model . 

5.4.3  MODEL  ARCHITECTURE 

The  DB  Model  consists  of  two  Model  Types; 

•  A  model  to  describe  the  behavior  of  the  nost  sifes  and 

•  A  model  to  describe  the  behavior  of  switching  nodes. 

5.4.3. 1  Host  Sites 

The  function  of  the  host  site  is  to  generate  new  messages  and  destroy  messages 
sent  from  other  host  nodes.  Each  host  site  consists  of; 

•  A  host  processor 

•  A  Network  Interface  Processor  (NIP) 

•  A  variable  number  of  internodal  transmission  devices 

•  2  Channels 

•  1  Buffer 

•  10  Terminals 

•  10  Disk  Drives 

Tne  host  sites  in  the  Detail  Models  differ  from  host  sites  in  HLM  Models 
(Section  4)  by  allowing  hosts  to  perform  both  host  functions  and  switching 
functions.  Thus,  one  model  (Model  1  -  Host  Sites)  would  have  been  sufficien. 
to  simulate  the  different  complexity  levels,  however  two  models  -  Host  and 
Switch  -  were  retained.  The  Switching  Model  is  available  for  simulating  nodes 
performing  twitching  functions  exclusively. 
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1.4. 3. 1-1  graphically  protrays  tne  Host  Site  Configuration. 

.4. 3. 1-1  provides  a  summary  for  the  System  Description  for  the  Ho^t 


Figure  5.4.3. 1-1  Host  Site  Configuration 


Table  5. 4. 3. 1-1  Host  Site  Configuration 


DEVICE  NAME 

ECSS  DEVICE  TYPE 

PERFORMANCE  SPECIFICATIONS 

DOIA.CPU 
( Processor) 

EXECUTIONS  ANDS 

JOB  STORE  DEVICE 

500,000  INSTRUCTIONS 
/SEC 

DOIA.NIP 

(Network  Interface 
Processor) 

NETWORK  INPUT 

PROCESSOR  EXECUTES 

AND  JOB  STORE  DEVICES 

500,000  INSTRUCTIONS 
/SEC 

TOlA.MOl  (Internodal 
Transmission  Device) 

TRANSMISSION  DEVICE 

20,000  BYTES/SEC 

001 8. CHANNELS 
(Channel ) 

TRANSMISSION  DEVICE 

20,000  BYTES/SEC 

DOIO.BUF  (Buffer) 

STORAGE  DEVICE 

10,000  BYTES 

OOlC. TERMINAL 
(Terminal ) 

I/O  DEVICE 

9600  BYTES/SEC 

POIA.T.PATH 
(Internodal  Path) 

PATH 

CONNECT  DOIB. CHANNELS 

TO  DOIC  TERMINALS 
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5.4. 3.2  Switching  Nodes 

The  function  of  the  switching  node  is  to  accept  and  forward  messages  along  the 
network.  Each  switching  node  consists  of: 


•  A  Processor 

•  A  variable  number  of  Internodal  Transmission  devices 

•  A  Buffer 

The  Processor  ana  Suffer  declarations  are  provided  in  the  DSS  Switching 
'•'oael.  Tne  specifications  for  the  Internodal  Transmission  devices  are  defined 
in  the  TP. FILE.  Figure  5.4. 3. 2-1  displays  the  Switching  Node 

Configuration.  Table  5. 4. 3. 2-1  provides  a  summary  for  the  System  Description 
Section  for  the  switching  node. 
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Figure  5. 4. 3. 2-1  Switching  Node  Configuration  (Dedicated  Option) 
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Table  5. 4. 3. 2-1  System  Description  for  Switching  Node 


DEVICE 

NAME 

DEVICE 

TYPE 

ECSS 

PERFORMANCE 

SPECIFICATIONS 

D02A.CPU 

EXECUTION  AND 

500,000  INSTRUCTIONS/SEC 

(Processor) 

JOB  STORE  DEVICE 

T02A.M01  (Internodal 

TRANSMISSION 

30,000  BYTES/SEC 

Transmission  Device) 

DEVICES 

D02B.BUF 

STORAGE 

10,000  BYTES 

(Buffer) 

DEVICE 

P01A.N01.N02 

PATH 

CONNECTS  TOlA.MOl 

(Internodal  Path) 

TO  T02A.M02 

00321 


5-55 


5.4.4  FUNCTIONAL  LOGIC  FLOW 

Tuo  major  external  processes  provide  the  control  functions  (e.g.,  message 
generation  and  starting  computer  jobs)  for  the  DB  model.  They  are: 


•  ..ARR  process  (message  generation) 

•  CP  Process  (communication  process  -  controlling  computer  jobs) 

A  brief  description  of  each  process  is  provided: 

.'■lessaqe  Generation  -  External  Process  ..ARR 

The  ..ARR  process  provides  the  vehicle  for  generating  every  message  introduC'rd 
into  the  network.  This  process  simply  cycles  according  to  the  interarrivil 

rate  (MIT)  established  in  the  MESS  file  or  defaulted  in  the  EXEC  file. 

Messages  are  created  each  time  the  process  cycles.  The  number  of  instances  of 
..ARR  in  the  External  Process  Reports  indicates  the  number  of  different 
message  types  generated  during  the  simulation  run. 

Communication  Process  -  External  Process  CP 

The  primary  function  of  the  communication  process  is  to  control  the 

communication  between  nodes.  A  communication  process  may  start  jobs  on  a 

processing  unit  which  simulates  the  activity  of  transferring,  switching  and 
receiving  messages.  Statistics  on  tnese  external  processes  are  displayed  in 
the  External  Process  Report.  The  number  of  instances  for  the  CP  processes 
should  be  one.  These  processes  are  started  only  once  and  continue  to  operate 
for  the  full  duration  of  the  simulation. 


The  communication 


CO 

o 

5M 

JOB 

RM 

JOB 

HT 

JOB 

TH 

JOB 

HN 

JOB 

NH 

cess  activates  and 

JOB  AK 
JOB  PA 
JOB  PC 
JOB  RC 
JOB  RD 
JOB  SS 


controls  these  jobs: 


00321 


5-56 


f 


A  description  of  these  jobs  is  provided. 

JOB  $M  -  Message  Transferring 

JOB  SM  simulates  the  activity  of  transfering  a  message  from  a  current  site  to 
the  next  node.  It  accomplishes  this  task  by  filing  the  pointer  to  the  message 
(MSG)  data  in  the  switching  nodes  message  file  (..MGFIlE).  The  JOB  concludes 
by  signaling  the  switching  node.  This  notifies  the  communication  process  that 
it  has  a  message  waiting  for  it.  The  total  number  of  instances  for  a  unique 
JOB  SM  can  be  interpreted  as  the  total  number  of  messages  transmitted  from  one 
site  to  another. 

JOB  RM  -  Retransmit  Message 

JOB  RM  simulates  the  retransmission  of  a  message  if  an  acknowledgement  has  not 
been  received  within  a  user  specified  time.  The  number  of  instances  of  JOB  RM 
indicates  the  number  of  packets  sent  from  a  particular  node  which  were 
rejected  by  an  adjacent  node. 

JOB  AK-  Acknowledgement 

JOB  AK  is  responsible  for  sending  acknowledgements  for  accepted  packets.  This 
job  is  only  operational  when  a  "1"  is  indicated  for  "ACK"  in  the  EXEC  file. 
The  number  of  instances  of  JOB  AK  indicates  the  number  of  packets  accepted  by 
a  particular  node. 

JOB  PA  -  Packet  Assembly 

JOB  PA  simulates  the  reassembly  of  a  message  at  the  NIP.  The  number  of 
instance  of  JOB  PA  indicates  the  total  number  of  completely  reassembled 
messages  at  a  host  node. 

JOB  PC  -  Post  Communication 

JOB  PC  is  the  timing  mechanism  that  schedules  the  retransmit  command  for  all 
unacknowledged  packets.  The  user  specifies  the  frequency  in  which  this  job  is 
performed  by  selecting  the  maximum  response  time  tolerable  for  all 
acknowledgements  at  the  host  (TMH)  and  switching  nodes  (TMC).  The  number  of 
instances  of  this  job  indicates  how  many  times  a  particular  node  assessed  the 
status  of  its  outgoing  packets. 
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JOB  TH-  Terminal  to  Host  Transmission 

This  job  simulater  the  trahsfering  of  a  message  from  a  host  site's  terminal  to 
the  Host  processor.  Tasks  accomplished  by  this  job  are; 

•  Sending  appropriate  bytes  from  a  randomly  selected  terminal  via  a 
randomly  selected  channel, 

•  Message  type  is  changed  from  a  new  message  (Type  1)  to  'received  at 
Host'.  (Type  2). 

•  Message  is  then  filed  in  current  node's  message  file, 

•  CP  is  signaled. 

» 

The  numoer  of  unique  occurances  of  this  job  can  be  interpreted  as  total 
messages  received  at  that  host  from  its  users. 

JOB  HN-  Host  to  NIP  Transfer 

This  job  increases  simulation  time  to  model  the  overhead  incurred  by  the  HOoT 
CPU  when  relaying  a  message  to  its  Network  Interface  Processor  (NIP).  JOB  HN 
accomplishes  this  by  changing  message  type  to  'received  at  NIP'  (Type  3), 
filing  the  message  in  its  message  file  and  signaling  CP.  Total  number  of 
instances  for  this  job  for  any  given  node,  represents  total  number  of  messages 
entered  into  network. 

JOB  NH-  NIP  to  Host  Transfer 

This  job  incurs  simulation  time  to  represent  overhead  when  messages  flow  from 
a  Host  Site  NIP  to  its  Host  CPU.  Total  number  of  instances  for  that  node 
represent  number  of  messages  received  by  that  node  from  the  network. 

JOB  HT  -  Host  to  Terminal  Transfer 

This  job  simulates  the  transferring  of  a  message  from  a  Host  CPU  to  its 
terminals.  It  accomplishes  this  by  sending  appropriate  bytes  via  a  randomly 
selected  channel  to  a  randomly  selected  terminal.  Total  number  of  instances 
for  this  job  for  any  given  node  represents  communication  activity  between  CPU 
and  its  terminals. 
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JOB  RC  -  Reroute  for  Congestion 

This  job  simulates  the  selection  of  a  new  virtual  circuit  when  the  next  node 
in  the  correct  virtual  circuit  is  out  of  buffer  space.  Total  number  of 
instances  represents  network  rerouting  due  to  traffic  overload. 

JOB  RD  -  Reroute  because  of  Nodal  Failure 

This  job  simulates  the  selection  of  a  new  virtual  circuit  when  the  next  node 
in  the  current  virtual  circuit  is  disconnected  from  the  network.  Total  number 
of  instances  represents  network  rerouting  due  to  nodal  failures. 

JOB  SS  -  Staggered  Signal 

This  job  staggers  the  signal  to  the  External  Process  TM  (Transaction  Manager) 
to  prevent  simultaneous  (occurring  in  the  same  simulation  time  segment) 
signals  from  being  interpreted  as  the  same  signal. 

EXTERNAL  PROCESS  -  RECOV 

Controls  the  time  interval  a  node  is  unavailable  to  the  network.  When  the 
External  Process  RECOV  is  signalled  after  the  duration  of  the  crash,  the 
node's  status  is  toggled  to  1  (up). 

EXTERNAL  PROCESS  -  CRASH 

Controls  the  time  interval  between  failures  for  a  network  node.  After  a  time 
interval  has  elapsed,  the  External  Process  Crash  is  signaled  and  the  node's 
status  is  toggled  to  0  (Down). 


CRASH 

RECOV 

CRASH 

STATUS  «  1 

STATUS  =  0  STATUS  =  1 

STATUS  =  0 

A  ..  _ 

A  _ 

A  .  _ 

A  _  . 

^1 

^2 

^3 

^4 

Figure  5. 4. 4-1  External  Process  CRASH  and  RECOV  Relationship 


Figure  5. 4. 4-1  shows  the  relationship  between  DB  model's  external  process 
CRASH  and  external  process  RECOV  (See  5. 3.4. 2  R/A's  Nodal  Failures). 


One  new  External  Process  was  added  to  tne  DU. 


External  Process  TM  -  Transaction  Manager 

This  External  Process  supervises  the  interaction  between  transactions  and  tiie 
Distributed  Database  Management  System  (DDBMS).  Refer  to  Section  5. 4. 1.2  for 
a  detailed  description  of  TM. 


Section  5.4.1  explained  how  the  Distributed  Database  Management  System 
Architecture  was  used  as  a  framework  to  implement  the  DB  model.  Each  of  the 
three  submodels  DT,  TM  and  UM,  were  describeo.  Tms  section  will  cover  the 
functional  logic  flow  of  the  TM  to  DM  interactions.  When  a  transaction 
arrives  at  a  host,  the  TM  explodes  the  transaction  into  individual  read  and 

write  operations.  Each  read  or  write  operation  is  routed  to  either  its  host 

application  level  or  a  remote  host's  application  level  oepending  on  file 

location.  A  read  will  always  be  routed  to  the  current  node's  application 
level  if  the  target  file  exists  at  that  site.  Writes  are  ouplicated  for  every 
node  at  which  the  target  file  is  located  (See  5. 4. 1.2).  Upon  arrival  at  the 
appropriate  application  site's  level,  the  DM  checks  the  operation's  timestamp 
against  the  timestamp  of  the  last  successful  operation  to  access  the  target 
file.  If  the  operation  is  out-of-sequence,  the  DM  rejects  the  operation  and 
reroutes  the  operation  back  to  the  originating  TM.  Otherwise,  the  UM 

processes  the  operation,  updates  the  file's  last  access  timestamp  and  returns 
the  operation  to  originating  TM  as  successful  (See  5. 4. 1.3). 


As  tne  TM  receives  the  returning  operation,  the  TM  checks  for  rejections.  If 
any  operation  was  rejected  by  a  DM,  the  entire  transaction  with  its  original 
R/W  operations  is  restarted.  Once  all  transactions  are  received,  the  TM  sends 
a  message  to  the  originating  terminal,  appropriately  advising  "transaction 
completed"  or  "transaction  restarted".  Figure  5. 4. 4-2  displays  the  Functional 
Logic  flow  for  the  TM-DM  interactions. 
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TRANSACTION 

ARRIVES 


Figure  5. 4, 4-2  Functional  Logic  Flow  for  TM-DM  Interactions 
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5.4.5  SIMULATION  OUTPUT 

Tne  OSS  Simulator  produces  two  classes  of  output  reports: 


•  Transaction  Statistics 

•  ECSS  Standard  Reports 

(See  Appendix  F  for  examples  ) 


For  a  description  of  each  report  contained  in  this  section  refer  to  Section 
2.4  of  the  User's  Manual.  For  a  complete  sample  of  these  reports  refer  to 
Asse'C  X  r.  A  jar."ple  of  these  reports  follows. 
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MESSAGE  STATISTICS 


NO.  NO.  AV6. 

OmETEO  RESTARTED  RESTARTED 
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NUMBER  OF  TRANSMISSIONS  TRANS  PERCENTAGE  —  TRANSMISSION  LENGTH  --  %  TIME 

DEVICE  NAME  lOTAL  AVERAGE  STD  DEV  MAXIMUM  CAPACITY  UTILIZATION  AVERAGE  MAXIMUM  IDLE 
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